From stefan.karlsson at oracle.com  Mon Oct  1 05:04:02 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 01 Oct 2012 14:04:02 +0200
Subject: Review request (XS): 8000227: [obj|type]ArrayKlass::oop_print_on
	prints one line to tty instead of the provided output stream
Message-ID: <506986B2.7090602@oracle.com>

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

StefanK

From keith.mcguigan at oracle.com  Mon Oct  1 05:22:57 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Mon, 01 Oct 2012 08:22:57 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <5065A634.1050600@oracle.com>
References: <5065A634.1050600@oracle.com>
Message-ID: <50698B21.7030208@oracle.com>


Those lines in jni.cpp are bordering on "ludicrous" character length, 
IMO.  I know we don't have an hard-set character limit (much to my 
chagrin), but we should at least try to keep it reasonable to and close 
what else is in the surrounding code.  (My bad for not mentioning this 
eariler.)

The rest looks good to me.

--
- Keith

On 9/28/2012 9:29 AM, Coleen Phillimore wrote:
> Summary: Don't use HS_DTRACE_PROBE_CDECL_N and HS_DTRACE_PROBE_N directly.
> Contributed-by: Mark Wielaard <mjw at redhat.com>
>
> I made a small change to dtrace.hpp to fix code for bsd when
> ENABLE_DTRACE is true, and moved the test.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/7170638/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>
> Tested against nsk.dtrace.testlist and test in the patch.   Built on bsd.
>
> Thanks,
> Coleen

From bengt.rutisson at oracle.com  Mon Oct  1 06:06:50 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 01 Oct 2012 15:06:50 +0200
Subject: Review request (XS): 8000227: [obj|type]ArrayKlass::oop_print_on
	prints one line to tty instead of the provided output stream
In-Reply-To: <506986B2.7090602@oracle.com>
References: <506986B2.7090602@oracle.com>
Message-ID: <5069956A.3090700@oracle.com>

On 2012-10-01 14:04, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8000227/webrev/
>
> StefanK

Looks good.

Bengt


From staffan.larsen at oracle.com  Mon Oct  1 07:19:35 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 1 Oct 2012 07:19:35 -0700
Subject: Review request (XS): 8000227: [obj|type]ArrayKlass::oop_print_on
	prints one line to tty instead of the provided output stream
In-Reply-To: <506986B2.7090602@oracle.com>
References: <506986B2.7090602@oracle.com>
Message-ID: <624D08AF-D30B-4478-998E-770B7BFD8AFB@oracle.com>

Looks good.

On 1 okt 2012, at 05:04, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:

> http://cr.openjdk.java.net/~stefank/8000227/webrev/
> 
> StefanK


From coleen.phillimore at oracle.com  Mon Oct  1 08:27:08 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 01 Oct 2012 11:27:08 -0400
Subject: Review request (XS): 8000227: [obj|type]ArrayKlass::oop_print_on
	prints one line to tty instead of the provided output stream
In-Reply-To: <624D08AF-D30B-4478-998E-770B7BFD8AFB@oracle.com>
References: <506986B2.7090602@oracle.com>
	<624D08AF-D30B-4478-998E-770B7BFD8AFB@oracle.com>
Message-ID: <5069B64C.7080501@oracle.com>

Looks good.
Coleen

On 10/1/2012 10:19 AM, Staffan Larsen wrote:
> Looks good.
>
> On 1 okt 2012, at 05:04, Stefan Karlsson<stefan.karlsson at oracle.com>  wrote:
>
>> http://cr.openjdk.java.net/~stefank/8000227/webrev/
>>
>> StefanK

From mark at klomp.org  Mon Oct  1 11:20:32 2012
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 01 Oct 2012 20:20:32 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <50698B21.7030208@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
Message-ID: <1349115632.2682.122.camel@springer.wildebeest.org>

On Mon, 2012-10-01 at 08:22 -0400, Keith McGuigan wrote:
> Those lines in jni.cpp are bordering on "ludicrous" character length, 
> IMO.  I know we don't have an hard-set character limit (much to my 
> chagrin), but we should at least try to keep it reasonable to and close 
> what else is in the surrounding code.  (My bad for not mentioning this 
> eariler.)

Please feel free to add a \ line continuation before the second
DTRACE_PROBE macro on each line. That would still be ~100 character, but
that would be shorter than some of the surrounding code, and seems like
a "natural" break place. Normally I don't like such long lines either
and keep to < 76 so things fit nicely in my terminal window, but since
this file already had 160+ character lines I thought I would go with the
flow.

> The rest looks good to me.

Thanks,

Mark

From vladimir.kozlov at oracle.com  Mon Oct  1 12:24:33 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 01 Oct 2012 12:24:33 -0700
Subject: Result: New HSX Committer: Krystal Mo
Message-ID: <5069EDF1.2080404@oracle.com>

Voting for Krystal Mo [1] is now closed.

Yes: 18
Veto: 0
Abstain: 25

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

Vladimir Kozlov

[1]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006515.html
[2] http://openjdk.java.net/bylaws#lazy-consensus



From coleen.phillimore at oracle.com  Mon Oct  1 12:50:00 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 01 Oct 2012 15:50:00 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349115632.2682.122.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
Message-ID: <5069F3E8.10600@oracle.com>


http://cr.openjdk.java.net/~coleenp/7170638/src/share/vm/prims/jni.cpp.udiff.html

In jni.cpp it looks like the macro change was a cleanup (?) but what 
happened to this?  It seems to have gone away with the macro change?

*!    HS_DTRACE_PROBE_CDECL_N(hotspot_jni, SetStatic##Result##Field__entry,\*
*       ( JNIEnv*, jclass, jfieldID FP_SELECT_##Result(COMMA Argument,/*empty*/) ) ); \
*

On Solaris the  DECL_N things add the extern "C" declaration.

// Solaris dtrace needs actual extern function decls.
#define HS_DTRACE_PROBE_DECL_N(provider,name,args) \
   DTRACE_ONLY(extern "C" void HS_DTRACE_PROBE_FN(provider,name) args)

I tested solaris and it worked but I don't know how the extern "C" 
declaration got declared.

Thanks,
Coleen

On 10/1/2012 2:20 PM, Mark Wielaard wrote:
> On Mon, 2012-10-01 at 08:22 -0400, Keith McGuigan wrote:
>> Those lines in jni.cpp are bordering on "ludicrous" character length,
>> IMO.  I know we don't have an hard-set character limit (much to my
>> chagrin), but we should at least try to keep it reasonable to and close
>> what else is in the surrounding code.  (My bad for not mentioning this
>> eariler.)
> Please feel free to add a \ line continuation before the second
> DTRACE_PROBE macro on each line. That would still be ~100 character, but
> that would be shorter than some of the surrounding code, and seems like
> a "natural" break place. Normally I don't like such long lines either
> and keep to<  76 so things fit nicely in my terminal window, but since
> this file already had 160+ character lines I thought I would go with the
> flow.
>
>> The rest looks good to me.
> Thanks,
>
> Mark

From mjw at redhat.com  Mon Oct  1 13:02:19 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Mon, 01 Oct 2012 22:02:19 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <5069F3E8.10600@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
Message-ID: <1349121739.2682.128.camel@springer.wildebeest.org>

On Mon, 2012-10-01 at 15:50 -0400, Coleen Phillimore wrote:
> http://cr.openjdk.java.net/~coleenp/7170638/src/share/vm/prims/jni.cpp.udiff.html
> 
> In jni.cpp it looks like the macro change was a cleanup (?) but what 
> happened to this?  It seems to have gone away with the macro change?
> 
> *!    HS_DTRACE_PROBE_CDECL_N(hotspot_jni, SetStatic##Result##Field__entry,\*
> *       ( JNIEnv*, jclass, jfieldID FP_SELECT_##Result(COMMA Argument,/*empty*/) ) ); \
> *
> 
> On Solaris the  DECL_N things add the extern "C" declaration.
> 
> // Solaris dtrace needs actual extern function decls.
> #define HS_DTRACE_PROBE_DECL_N(provider,name,args) \
>    DTRACE_ONLY(extern "C" void HS_DTRACE_PROBE_FN(provider,name) args)
> 
> I tested solaris and it worked but I don't know how the extern "C" 
> declaration got declared.

See also the explanation that was submitted with the original patch:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005739.html

But yes, that is basically precisely what the cleanup does. Instead of
having to specify things twice using two different macros
HS_DTRACE_PROBE_CDECL_N and then HS_DTRACE_PROBE_N. Just use what the
rest of the jni.cpp file uses, the DTRACE_PROBEN macro which does both
of them if needed.

Cheers,

Mark

From coleen.phillimore at oracle.com  Mon Oct  1 13:49:21 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 01 Oct 2012 16:49:21 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349121739.2682.128.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
Message-ID: <506A01D1.8020604@oracle.com>


Oh good, I see that.

I have another question.   You check for the presence of  
/usr/include/sys/sdt.h to set DTRACE_ENABLED.   Is this file installed 
with gcc versions 4.5+ or can it be installed with a latest version of 
linux?   Is dtrace only supported with gcc 4.5+ or only supported with a 
version of linux that enables this?

If we upgraded our tool chains to be gcc 4.5+ (4.7) does that mean we 
might enable this?   Or is it tied to the linux version?  Does this 
question make sense?

Thanks,
Coleen

On 10/1/2012 4:02 PM, Mark Wielaard wrote:
> On Mon, 2012-10-01 at 15:50 -0400, Coleen Phillimore wrote:
>> http://cr.openjdk.java.net/~coleenp/7170638/src/share/vm/prims/jni.cpp.udiff.html
>>
>> In jni.cpp it looks like the macro change was a cleanup (?) but what
>> happened to this?  It seems to have gone away with the macro change?
>>
>> *!    HS_DTRACE_PROBE_CDECL_N(hotspot_jni, SetStatic##Result##Field__entry,\*
>> *       ( JNIEnv*, jclass, jfieldID FP_SELECT_##Result(COMMA Argument,/*empty*/) ) ); \
>> *
>>
>> On Solaris the  DECL_N things add the extern "C" declaration.
>>
>> // Solaris dtrace needs actual extern function decls.
>> #define HS_DTRACE_PROBE_DECL_N(provider,name,args) \
>>     DTRACE_ONLY(extern "C" void HS_DTRACE_PROBE_FN(provider,name) args)
>>
>> I tested solaris and it worked but I don't know how the extern "C"
>> declaration got declared.
> See also the explanation that was submitted with the original patch:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005739.html
>
> But yes, that is basically precisely what the cleanup does. Instead of
> having to specify things twice using two different macros
> HS_DTRACE_PROBE_CDECL_N and then HS_DTRACE_PROBE_N. Just use what the
> rest of the jni.cpp file uses, the DTRACE_PROBEN macro which does both
> of them if needed.
>
> Cheers,
>
> Mark

From john.cuthbertson at oracle.com  Mon Oct  1 13:55:14 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 01 Oct 2012 13:55:14 -0700
Subject: Request for review - 7199349
In-Reply-To: <506639E0.9090402@oracle.com>
References: <506639E0.9090402@oracle.com>
Message-ID: <506A0332.7040702@oracle.com>

Hi Jon,

Looks good to me.

JohnC

On 09/28/12 16:59, Jon Masamitsu wrote:
> 7199349: NPG: PS: Crash seen in jprt
>
> The error is caused by the calculation in scavenge_contents_parallel()
> of start_card and end_card where end_card was incorrectly set beyond
> start_card.  The incorrect code had been introduced to fix a problem
> exposed when the card table for perm gen was removed.  That first
> problem was an assertion error resulting when byte_for() was passed
> an addressed not covered by the card table.   I reverted to
> the previous code and do not invoke this code when the old gen
> is empty.  scavenge_contents_parallel() processes the card table
> to find old-to-young pointers and so is not needed in that case.
>
> Added a delay in two places in the young collection to widen the
> opportunity for these circumstances to occur.
>
> http://cr.openjdk.java.net/~jmasa/7199349
>
> Thanks to StefanK for his analysis of the problem.


From mjw at redhat.com  Mon Oct  1 14:24:27 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Mon, 1 Oct 2012 23:24:27 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506A01D1.8020604@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
Message-ID: <20121001212426.GA7120@toonder.wildebeest.org>

On Mon, Oct 01, 2012 at 04:49:21PM -0400, Coleen Phillimore wrote:
> I have another question.   You check for the presence of
> /usr/include/sys/sdt.h to set DTRACE_ENABLED.

Yes, see the last paragraph of the original submission to see why
I chose that method of testing:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005739.html
Basically because that looked most like what the existing
make/solaris/dtrace.make and vm.make files did.

> Is this file
> installed with gcc versions 4.5+ or can it be installed with a
> latest version of linux?

I am not entirely sure what you mean by "latest version of linux".
But the SystemTap package provides sys/sdt.h (in particular the
systemtap-sdt-devel sub-package).

The header file is described here:
http://tromey.com/blog/?p=687
http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation

Although it is installed by the Systemtap package, it isn't really
tied to Systemtap. It really just implements the SDT macros and
when included and compiled into an application that uses those
macros any application (stap, gdb, etc) that can read the ELF
probes notes section can use them.

> Is dtrace only supported with gcc 4.5+ or
> only supported with a version of linux that enables this?

I don't believe dtrace is supported with any version of gcc,
but I don't really know anything about dtrace.
The sys/sdt.h header (for C++) uses some features of GCC 4.5+.
(For plain C older GCC versions can be used, but hotspot is all C++.)

> If we upgraded our tool chains to be gcc 4.5+ (4.7) does that mean
> we might enable this?   Or is it tied to the linux version?  Does
> this question make sense?

I am not sure I understand the question. If you mean by "linux" the
kernel then the answer is that it doesn't depend in any way on the
kernel version. If you upgrade your toolchain to GCC 4.5+ and install
the sys/sdt.h header, then you can enable this.

Cheers,

Mark

From david.holmes at oracle.com  Mon Oct  1 14:30:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 02 Oct 2012 07:30:49 +1000
Subject: Result: New HSX Committer: Krystal Mo
In-Reply-To: <5069EDF1.2080404@oracle.com>
References: <5069EDF1.2080404@oracle.com>
Message-ID: <506A0B89.8080509@oracle.com>

Hi Vladimir,

Just a point of order ...

On 2/10/2012 5:24 AM, Vladimir Kozlov wrote:
> Voting for Krystal Mo [1] is now closed.
>
> Yes: 18
> Veto: 0
> Abstain: 25

I don't recall seeing anyone actually register an abstain vote. Not 
voting is not the same as voting "Abstain".

Cheers,
David

> According to the Bylaws definition of Lazy Consensus [2], this is
> sufficient to approve the nomination.
>
> Vladimir Kozlov
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006515.html
>
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>
>

From mjw at redhat.com  Mon Oct  1 14:32:36 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Mon, 1 Oct 2012 23:32:36 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349115632.2682.122.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
Message-ID: <20121001213236.GB7120@toonder.wildebeest.org>

On Mon, Oct 01, 2012 at 08:20:32PM +0200, Mark Wielaard wrote:
> On Mon, 2012-10-01 at 08:22 -0400, Keith McGuigan wrote:
> > Those lines in jni.cpp are bordering on "ludicrous" character length, 
> > IMO.  I know we don't have an hard-set character limit (much to my 
> > chagrin), but we should at least try to keep it reasonable to and close 
> > what else is in the surrounding code.  (My bad for not mentioning this 
> > eariler.)
> 
> Please feel free to add a \ line continuation before the second
> DTRACE_PROBE macro on each line. That would still be ~100 character, but
> that would be shorter than some of the surrounding code, and seems like
> a "natural" break place. Normally I don't like such long lines either
> and keep to < 76 so things fit nicely in my terminal window, but since
> this file already had 160+ character lines I thought I would go with the
> flow.

The attached jni.cpp patch does this and seems to work for me.

Cheers,

Mark
-------------- next part --------------
# 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.
# Contributed-by: Mark Wielaard <mjw at redhat.com>

--- openjdk/hotspot/src/share/vm/prims/jni.cpp	2012-10-01 21:32:29.382193266 +0200
+++ openjdk/hotspot/src/share/vm/prims/jni.cpp	2012-10-01 21:34:42.061549400 +0200
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012 Red Hat, Inc.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -2820,10 +2821,8 @@
 JNI_QUICK_ENTRY(void, jni_Set##Result##Field(JNIEnv *env, jobject obj, jfieldID fieldID, Argument value)) \
   JNIWrapper("Set" XSTR(Result) "Field"); \
 \
-  HS_DTRACE_PROBE_CDECL_N(hotspot_jni, Set##Result##Field__entry, \
-    ( JNIEnv*, jobject, jfieldID FP_SELECT_##Result(COMMA Argument,/*empty*/) ) ); \
-  HS_DTRACE_PROBE_N(hotspot_jni, Set##Result##Field__entry, \
-    ( env, obj, fieldID FP_SELECT_##Result(COMMA value,/*empty*/) ) ); \
+  FP_SELECT_##Result(DTRACE_PROBE4(hotspot_jni, Set##Result##Field__entry, env, obj, fieldID, value), \
+                     DTRACE_PROBE3(hotspot_jni, Set##Result##Field__entry, env, obj, fieldID)); \
 \
   oop o = JNIHandles::resolve_non_null(obj); \
   Klass* k = o->klass(); \
@@ -3130,10 +3129,8 @@
 \
 JNI_ENTRY(void, jni_SetStatic##Result##Field(JNIEnv *env, jclass clazz, jfieldID fieldID, Argument value)) \
   JNIWrapper("SetStatic" XSTR(Result) "Field"); \
-  HS_DTRACE_PROBE_CDECL_N(hotspot_jni, SetStatic##Result##Field__entry,\
-    ( JNIEnv*, jclass, jfieldID FP_SELECT_##Result(COMMA Argument,/*empty*/) ) ); \
-  HS_DTRACE_PROBE_N(hotspot_jni, SetStatic##Result##Field__entry, \
-    ( env, clazz, fieldID FP_SELECT_##Result(COMMA value,/*empty*/) ) ); \
+  FP_SELECT_##Result(DTRACE_PROBE4(hotspot_jni, SetStatic##Result##Field__entry, env, clazz, fieldID, value), \
+                     DTRACE_PROBE3(hotspot_jni, SetStatic##Result##Field__entry, env, clazz, fieldID)); \
 \
   JNIid* id = jfieldIDWorkaround::from_static_jfieldID(fieldID); \
   assert(id->is_static_field_id(), "invalid static field id"); \

From vladimir.kozlov at oracle.com  Mon Oct  1 14:49:22 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 01 Oct 2012 14:49:22 -0700
Subject: Result: New HSX Committer: Krystal Mo
Message-ID: <506A0FE2.4060909@oracle.com>

Voting for Krystal Mo [1] is now closed.

Yes: 18
Veto: 0
Abstain: 0

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

Resend with corrected "Abstain" number.

Vladimir Kozlov

[1]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006515.html
[2] http://openjdk.java.net/bylaws#lazy-consensus



From vladimir.kozlov at oracle.com  Mon Oct  1 14:50:31 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 01 Oct 2012 14:50:31 -0700
Subject: Result: New HSX Committer: Krystal Mo
In-Reply-To: <506A0B89.8080509@oracle.com>
References: <5069EDF1.2080404@oracle.com> <506A0B89.8080509@oracle.com>
Message-ID: <506A1027.5000209@oracle.com>

Thank you, David

I resend the result with corrected "Abstain".

Vladimir

David Holmes wrote:
> Hi Vladimir,
> 
> Just a point of order ...
> 
> On 2/10/2012 5:24 AM, Vladimir Kozlov wrote:
>> Voting for Krystal Mo [1] is now closed.
>>
>> Yes: 18
>> Veto: 0
>> Abstain: 25
> 
> I don't recall seeing anyone actually register an abstain vote. Not 
> voting is not the same as voting "Abstain".
> 
> Cheers,
> David
> 
>> According to the Bylaws definition of Lazy Consensus [2], this is
>> sufficient to approve the nomination.
>>
>> Vladimir Kozlov
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006515.html 
>>
>>
>> [2] http://openjdk.java.net/bylaws#lazy-consensus
>>
>>

From jon.masamitsu at oracle.com  Mon Oct  1 14:51:33 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 01 Oct 2012 14:51:33 -0700
Subject: Request for review - 7199349
In-Reply-To: <506A0332.7040702@oracle.com>
References: <506639E0.9090402@oracle.com> <506A0332.7040702@oracle.com>
Message-ID: <506A1065.8030707@oracle.com>

Thanks.

On 10/01/12 13:55, John Cuthbertson wrote:
> Hi Jon,
>
> Looks good to me.
>
> JohnC
>
> On 09/28/12 16:59, Jon Masamitsu wrote:
>> 7199349: NPG: PS: Crash seen in jprt
>>
>> The error is caused by the calculation in scavenge_contents_parallel()
>> of start_card and end_card where end_card was incorrectly set beyond
>> start_card.  The incorrect code had been introduced to fix a problem
>> exposed when the card table for perm gen was removed.  That first
>> problem was an assertion error resulting when byte_for() was passed
>> an addressed not covered by the card table.   I reverted to
>> the previous code and do not invoke this code when the old gen
>> is empty.  scavenge_contents_parallel() processes the card table
>> to find old-to-young pointers and so is not needed in that case.
>>
>> Added a delay in two places in the young collection to widen the
>> opportunity for these circumstances to occur.
>>
>> http://cr.openjdk.java.net/~jmasa/7199349
>>
>> Thanks to StefanK for his analysis of the problem.
>

From coleen.phillimore at oracle.com  Mon Oct  1 15:13:18 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 01 Oct 2012 18:13:18 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <20121001213236.GB7120@toonder.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<20121001213236.GB7120@toonder.wildebeest.org>
Message-ID: <506A157E.4070504@oracle.com>


Yes, I've done similar reformatting for that macro, see:
http://cr.openjdk.java.net/~coleenp/7170638_2/
Coleen

On 10/1/2012 5:32 PM, Mark Wielaard wrote:
> On Mon, Oct 01, 2012 at 08:20:32PM +0200, Mark Wielaard wrote:
>> On Mon, 2012-10-01 at 08:22 -0400, Keith McGuigan wrote:
>>> Those lines in jni.cpp are bordering on "ludicrous" character length,
>>> IMO.  I know we don't have an hard-set character limit (much to my
>>> chagrin), but we should at least try to keep it reasonable to and close
>>> what else is in the surrounding code.  (My bad for not mentioning this
>>> eariler.)
>> Please feel free to add a \ line continuation before the second
>> DTRACE_PROBE macro on each line. That would still be ~100 character, but
>> that would be shorter than some of the surrounding code, and seems like
>> a "natural" break place. Normally I don't like such long lines either
>> and keep to<  76 so things fit nicely in my terminal window, but since
>> this file already had 160+ character lines I thought I would go with the
>> flow.
> The attached jni.cpp patch does this and seems to work for me.
>
> Cheers,
>
> Mark

From coleen.phillimore at oracle.com  Mon Oct  1 15:31:16 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 01 Oct 2012 18:31:16 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <20121001212426.GA7120@toonder.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
Message-ID: <506A19B4.7040200@oracle.com>


Okay, my question was out of ignorance.  To get this functionality, you 
need to install both the Systemtap package and upgrade the compilers.  
Doing the second is not sufficient to get this support.   It's just 
required for the elf section changes.

Thanks,
Coleen

On 10/1/2012 5:24 PM, Mark Wielaard wrote:
> On Mon, Oct 01, 2012 at 04:49:21PM -0400, Coleen Phillimore wrote:
>> I have another question.   You check for the presence of
>> /usr/include/sys/sdt.h to set DTRACE_ENABLED.
> Yes, see the last paragraph of the original submission to see why
> I chose that method of testing:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005739.html
> Basically because that looked most like what the existing
> make/solaris/dtrace.make and vm.make files did.
>
>> Is this file
>> installed with gcc versions 4.5+ or can it be installed with a
>> latest version of linux?
> I am not entirely sure what you mean by "latest version of linux".
> But the SystemTap package provides sys/sdt.h (in particular the
> systemtap-sdt-devel sub-package).
>
> The header file is described here:
> http://tromey.com/blog/?p=687
> http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
>
> Although it is installed by the Systemtap package, it isn't really
> tied to Systemtap. It really just implements the SDT macros and
> when included and compiled into an application that uses those
> macros any application (stap, gdb, etc) that can read the ELF
> probes notes section can use them.
>
>> Is dtrace only supported with gcc 4.5+ or
>> only supported with a version of linux that enables this?
> I don't believe dtrace is supported with any version of gcc,
> but I don't really know anything about dtrace.
> The sys/sdt.h header (for C++) uses some features of GCC 4.5+.
> (For plain C older GCC versions can be used, but hotspot is all C++.)
>
>> If we upgraded our tool chains to be gcc 4.5+ (4.7) does that mean
>> we might enable this?   Or is it tied to the linux version?  Does
>> this question make sense?
> I am not sure I understand the question. If you mean by "linux" the
> kernel then the answer is that it doesn't depend in any way on the
> kernel version. If you upgrade your toolchain to GCC 4.5+ and install
> the sys/sdt.h header, then you can enable this.
>
> Cheers,
>
> Mark

From karen.kinnear at oracle.com  Mon Oct  1 17:19:20 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 1 Oct 2012 20:19:20 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506A19B4.7040200@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
Message-ID: <90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>

Mark,

Could you help with a couple of other questions please.

1. If you build with an earlier version of gcc - e.g. 4.3 - what happens when you build?
And when you run?
- i.e. shouldn't the makefile conditional be on both the existence of sys/std.h and the gcc version?

2. If you build on gcc 4.5 with a system that has std.h - what happens if you run on
a system that does not have a version of SystemTap that supports dtrace->std?
Do you need a runtime check as well so there are not problems in the field?

thanks,
Karen

On Oct 1, 2012, at 6:31 PM, Coleen Phillimore wrote:

> 
> Okay, my question was out of ignorance.  To get this functionality, you need to install both the Systemtap package and upgrade the compilers.  Doing the second is not sufficient to get this support.   It's just required for the elf section changes.
> 
> Thanks,
> Coleen
> 
> On 10/1/2012 5:24 PM, Mark Wielaard wrote:
>> On Mon, Oct 01, 2012 at 04:49:21PM -0400, Coleen Phillimore wrote:
>>> I have another question.   You check for the presence of
>>> /usr/include/sys/sdt.h to set DTRACE_ENABLED.
>> Yes, see the last paragraph of the original submission to see why
>> I chose that method of testing:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005739.html
>> Basically because that looked most like what the existing
>> make/solaris/dtrace.make and vm.make files did.
>> 
>>> Is this file
>>> installed with gcc versions 4.5+ or can it be installed with a
>>> latest version of linux?
>> I am not entirely sure what you mean by "latest version of linux".
>> But the SystemTap package provides sys/sdt.h (in particular the
>> systemtap-sdt-devel sub-package).
>> 
>> The header file is described here:
>> http://tromey.com/blog/?p=687
>> http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
>> 
>> Although it is installed by the Systemtap package, it isn't really
>> tied to Systemtap. It really just implements the SDT macros and
>> when included and compiled into an application that uses those
>> macros any application (stap, gdb, etc) that can read the ELF
>> probes notes section can use them.
>> 
>>> Is dtrace only supported with gcc 4.5+ or
>>> only supported with a version of linux that enables this?
>> I don't believe dtrace is supported with any version of gcc,
>> but I don't really know anything about dtrace.
>> The sys/sdt.h header (for C++) uses some features of GCC 4.5+.
>> (For plain C older GCC versions can be used, but hotspot is all C++.)
>> 
>>> If we upgraded our tool chains to be gcc 4.5+ (4.7) does that mean
>>> we might enable this?   Or is it tied to the linux version?  Does
>>> this question make sense?
>> I am not sure I understand the question. If you mean by "linux" the
>> kernel then the answer is that it doesn't depend in any way on the
>> kernel version. If you upgrade your toolchain to GCC 4.5+ and install
>> the sys/sdt.h header, then you can enable this.
>> 
>> Cheers,
>> 
>> Mark


From krystal.mo at oracle.com  Mon Oct  1 19:07:21 2012
From: krystal.mo at oracle.com (Krystal Mo)
Date: Mon, 1 Oct 2012 19:07:21 -0700 (PDT)
Subject: Result: New HSX Committer: Krystal Mo
Message-ID: <05809940-bec9-44d8-bbc2-576312d0e8e5@default>

Thank you all!

- Kris

----- Original Message -----
From: vladimir.kozlov at oracle.com
To: hotspot-dev at openjdk.java.net
Cc: registrar at openjdk.java.net
Sent: Tuesday, October 2, 2012 5:51:35 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi
Subject: Result: New HSX Committer: Krystal Mo

Voting for Krystal Mo [1] is now closed.

Yes: 18
Veto: 0
Abstain: 0

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

Resend with corrected "Abstain" number.

Vladimir Kozlov

[1]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006515.html
[2] http://openjdk.java.net/bylaws#lazy-consensus



From mjw at redhat.com  Tue Oct  2 01:52:51 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Tue, 2 Oct 2012 10:52:51 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
Message-ID: <20121002085251.GA18223@toonder.wildebeest.org>

On Mon, Oct 01, 2012 at 08:19:20PM -0400, Karen Kinnear wrote:
> 1. If you build with an earlier version of gcc - e.g. 4.3 -
> what happens when you build?

Building with older gcc is fine as long as you don't enable/install
sys/sdt.h. If you do enable it, but don't have a new enough GCC you might
get a build failure.

> And when you run?

If it builds it runs, there are no runtime dependencies. See below.

> - i.e. shouldn't the makefile conditional be on both the existence
> of sys/std.h and the gcc version?

As explained in the original submission for IcedTea I have a configure
feature check so you don't have to depend on specific versions, but
the hotspot build seems to prefer setting variables for things you want.
So I followed that convention in the make file patch.
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006196.html
But a version check can be added. Does the attached patch work for you?
I put in 4.4 as minimum since that is the oldest GCC that I have installed
that seems to compile things fine.

> 2. If you build on gcc 4.5 with a system that has std.h - what happens
> if you run on a system that does not have a version of SystemTap that
> supports dtrace->std?
> Do you need a runtime check as well so there are not problems in the field?

You don't need any runtime checks since there are no runtime dependencies.
gdb or stap might take advantage of the markers if they are there, but they
are just like debuginfo. If it is there you can take advantage of it with
the right tools to trace/debug hotspot, otherwise it doesn't have any impact.

See also the explanation I gave here:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005846.html
 
Cheers,

Mark
-------------- next part --------------
# 7170638: Enable dtrace compatible sdt probes on GNU/Linux builds.
# Summary: If sys/sdt.h is found, then enable dtrace compatible sdt probes.
# Contributed-by: Mark Wielaard <mjw at redhat.com>

diff -r fab6fbf427d2 make/linux/makefiles/dtrace.make
--- a/make/linux/makefiles/dtrace.make	Sun Sep 30 23:24:12 2012 +0100
+++ b/make/linux/makefiles/dtrace.make	Tue Oct 02 09:40:10 2012 +0200
@@ -1,5 +1,6 @@
 #
 # Copyright (c) 2005, 2008, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2012 Red Hat, Inc.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -25,3 +26,31 @@
 # Linux does not build jvm_db
 LIBJVM_DB =
 
+# But it does have a SystemTap dtrace compatible sys/sdt.h
+ifneq ($(ALT_SDT_H),)
+  SDT_H_FILE = $(ALT_SDT_H)
+else
+# We need a recent GCC for the default, otherwise use non-existing file
+ifneq "$(shell expr \( $(CC_VER_MAJOR) \>= 4 \) \& \( $(CC_VER_MINOR) \>= 4 \) )" "0"
+  SDT_H_FILE = /usr/include/sys/sdt.h
+else
+  SDT_H_FILE = /NO/sys/sdt.h/gcc/too/old
+endif
+endif
+DTRACE_ENABLED = $(shell test -f $(SDT_H_FILE) && echo $(SDT_H_FILE))
+
+ifneq ($(DTRACE_ENABLED),)
+  CFLAGS += -DDTRACE_ENABLED
+endif
+
+# Phone target used in vm.make build target to check whether enabled.
+.PHONY: dtraceCheck
+ifeq ($(DTRACE_ENABLED),)
+dtraceCheck:
+	$(QUIETLY) echo "**NOTICE** Dtrace support disabled $(SDT_H_FILE) not found"
+else
+dtraceCheck:
+endif
+
+# It doesn't support HAVE_DTRACE_H though.
+
diff -r fab6fbf427d2 make/linux/makefiles/vm.make
--- a/make/linux/makefiles/vm.make	Sun Sep 30 23:24:12 2012 +0100
+++ b/make/linux/makefiles/vm.make	Tue Oct 02 09:40:10 2012 +0200
@@ -387,7 +387,7 @@
 
 #----------------------------------------------------------------------
 
-build: $(LIBJVM) $(LAUNCHER) $(LIBJSIG) $(LIBJVM_DB) $(BUILDLIBSAPROC) $(WB_JAR)
+build: $(LIBJVM) $(LAUNCHER) $(LIBJSIG) $(LIBJVM_DB) $(BUILDLIBSAPROC) dtraceCheck $(WB_JAR)
 
 install: install_jvm install_jsig install_saproc
 

From coleen.phillimore at oracle.com  Tue Oct  2 18:32:30 2012
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Tue, 02 Oct 2012 21:32:30 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <20121002085251.GA18223@toonder.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
Message-ID: <506B95AE.6070002@oracle.com>


I have changed the dtrace.make makefile a bit.   The JVM group at Oracle 
hasn't added support for SystemTap so I wanted to make sure that Oracle 
doesn't support this in the binaries and mistakenly enable this if we 
upgrade our build compilers or systems.    The dtrace probe support is 
now also guarded by an ifdef OPENJDK.  Do you build with OPENJDK=true 
when you build just hotspot binaries?  The JDK sets this variable in the 
Makefiles.

Please review and try the patch in this webrev.

http://cr.openjdk.java.net/~coleenp/7170638_3/ 
<http://cr.openjdk.java.net/%7Ecoleenp/7170638_3/>

Also is it possible for the test to do more than just test that the 
probes are enabled?  Or does it require some external tools?

Thanks,
Coleen

On 10/2/2012 4:52 AM, Mark Wielaard wrote:
> On Mon, Oct 01, 2012 at 08:19:20PM -0400, Karen Kinnear wrote:
>> 1. If you build with an earlier version of gcc - e.g. 4.3 -
>> what happens when you build?
> Building with older gcc is fine as long as you don't enable/install
> sys/sdt.h. If you do enable it, but don't have a new enough GCC you might
> get a build failure.
>
>> And when you run?
> If it builds it runs, there are no runtime dependencies. See below.
>
>> - i.e. shouldn't the makefile conditional be on both the existence
>> of sys/std.h and the gcc version?
> As explained in the original submission for IcedTea I have a configure
> feature check so you don't have to depend on specific versions, but
> the hotspot build seems to prefer setting variables for things you want.
> So I followed that convention in the make file patch.
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006196.html
> But a version check can be added. Does the attached patch work for you?
> I put in 4.4 as minimum since that is the oldest GCC that I have installed
> that seems to compile things fine.
>
>> 2. If you build on gcc 4.5 with a system that has std.h - what happens
>> if you run on a system that does not have a version of SystemTap that
>> supports dtrace->std?
>> Do you need a runtime check as well so there are not problems in the field?
> You don't need any runtime checks since there are no runtime dependencies.
> gdb or stap might take advantage of the markers if they are there, but they
> are just like debuginfo. If it is there you can take advantage of it with
> the right tools to trace/debug hotspot, otherwise it doesn't have any impact.
>
> See also the explanation I gave here:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005846.html
>
> Cheers,
>
> Mark

From mjw at redhat.com  Wed Oct  3 02:33:11 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Wed, 03 Oct 2012 11:33:11 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506B95AE.6070002@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
Message-ID: <1349256791.2682.163.camel@springer.wildebeest.org>

On Tue, 2012-10-02 at 21:32 -0400, Coleen Phillmore wrote:
> I have changed the dtrace.make makefile a bit.   The JVM group at Oracle 
> hasn't added support for SystemTap so I wanted to make sure that Oracle 
> doesn't support this in the binaries and mistakenly enable this if we 
> upgrade our build compilers or systems.    The dtrace probe support is 
> now also guarded by an ifdef OPENJDK.  Do you build with OPENJDK=true 
> when you build just hotspot binaries?  The JDK sets this variable in the 
> Makefiles.

No I don't use OPENJDK=true, just the normal build targets. As far as I
can see IcedTea also doesn't set it or uses any other target than the
default (or hotspot or jdk_only in case of alternative VMs).

Minor nit (please feel free to ignore). The reason text is a little
misleading, it should say something like:
REASON = "This JDK does not support SDT probes yet"
Whether you then use them with Systemtap (or GDB or some other tool that
can use them) seems irrelevant. (aka, it isn't hotspot supporting
Systemtap, it is Systemtap supporting DTrace compatible SDT probes).

> Please review and try the patch in this webrev.
> 
> http://cr.openjdk.java.net/~coleenp/7170638_3/ 
> <http://cr.openjdk.java.net/%7Ecoleenp/7170638_3/>

It doesn't seem to work for me. The conditional ifndef OPENJDK seems to
always evaluate to true in my setup.

Can you explain the OPENJDK=true setting a bit more? I don't see it
mentioned at:
http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#variables

I do see a Build Directives: OPENJDK = true in my build logs, but that
is not passed down to any subdir makes. Maybe it should be part of
COMMON_BUILD_ARGUMENTS in make/Defs-internal.gmk? Or maybe the hotspot
subdir make should call the sanity target first like the jdk subdir
does?

It does work for me if I change the conditional to
ifeq ($(OPENJDK),false). But I don't know if that is what you want.

> Also is it possible for the test to do more than just test that the 
> probes are enabled?  Or does it require some external tools?

That would require external tools (in this case I even was careful to
not use any newer feature of readelf, since only newer versions know how
to parse the ELF note section to parse out the probes). Given what a
nightmare it has been to just get a simple build fix in, I rather not
also try to push any new runtime features or new external tool
requirements :)

Thanks,

Mark

From keith.mcguigan at oracle.com  Wed Oct  3 04:53:52 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 3 Oct 2012 07:53:52 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506B95AE.6070002@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
Message-ID: <632E652F-BB8C-482E-9A24-4B9E37F5CF03@oracle.com>


Yes, it would certainly be nice to have some functional tests for this, if possible, but the code looks good to me if you need a reviewer.

--
- Keith

On Oct 2, 2012, at 9:32 PM, Coleen Phillmore wrote:

> 
> I have changed the dtrace.make makefile a bit.   The JVM group at Oracle hasn't added support for SystemTap so I wanted to make sure that Oracle doesn't support this in the binaries and mistakenly enable this if we upgrade our build compilers or systems.    The dtrace probe support is now also guarded by an ifdef OPENJDK.  Do you build with OPENJDK=true when you build just hotspot binaries?  The JDK sets this variable in the Makefiles.
> 
> Please review and try the patch in this webrev.
> 
> http://cr.openjdk.java.net/~coleenp/7170638_3/ <http://cr.openjdk.java.net/%7Ecoleenp/7170638_3/>
> 
> Also is it possible for the test to do more than just test that the probes are enabled?  Or does it require some external tools?
> 
> Thanks,
> Coleen
> 
> On 10/2/2012 4:52 AM, Mark Wielaard wrote:
>> On Mon, Oct 01, 2012 at 08:19:20PM -0400, Karen Kinnear wrote:
>>> 1. If you build with an earlier version of gcc - e.g. 4.3 -
>>> what happens when you build?
>> Building with older gcc is fine as long as you don't enable/install
>> sys/sdt.h. If you do enable it, but don't have a new enough GCC you might
>> get a build failure.
>> 
>>> And when you run?
>> If it builds it runs, there are no runtime dependencies. See below.
>> 
>>> - i.e. shouldn't the makefile conditional be on both the existence
>>> of sys/std.h and the gcc version?
>> As explained in the original submission for IcedTea I have a configure
>> feature check so you don't have to depend on specific versions, but
>> the hotspot build seems to prefer setting variables for things you want.
>> So I followed that convention in the make file patch.
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006196.html
>> But a version check can be added. Does the attached patch work for you?
>> I put in 4.4 as minimum since that is the oldest GCC that I have installed
>> that seems to compile things fine.
>> 
>>> 2. If you build on gcc 4.5 with a system that has std.h - what happens
>>> if you run on a system that does not have a version of SystemTap that
>>> supports dtrace->std?
>>> Do you need a runtime check as well so there are not problems in the field?
>> You don't need any runtime checks since there are no runtime dependencies.
>> gdb or stap might take advantage of the markers if they are there, but they
>> are just like debuginfo. If it is there you can take advantage of it with
>> the right tools to trace/debug hotspot, otherwise it doesn't have any impact.
>> 
>> See also the explanation I gave here:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005846.html
>> 
>> Cheers,
>> 
>> Mark


From david.holmes at oracle.com  Wed Oct  3 05:18:45 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 03 Oct 2012 22:18:45 +1000
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349256791.2682.163.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
Message-ID: <506C2D25.9020701@oracle.com>

On 3/10/2012 7:33 PM, Mark Wielaard wrote:
> On Tue, 2012-10-02 at 21:32 -0400, Coleen Phillmore wrote:
>> I have changed the dtrace.make makefile a bit.   The JVM group at Oracle
>> hasn't added support for SystemTap so I wanted to make sure that Oracle
>> doesn't support this in the binaries and mistakenly enable this if we
>> upgrade our build compilers or systems.    The dtrace probe support is
>> now also guarded by an ifdef OPENJDK.  Do you build with OPENJDK=true
>> when you build just hotspot binaries?  The JDK sets this variable in the
>> Makefiles.
>
> No I don't use OPENJDK=true, just the normal build targets. As far as I
> can see IcedTea also doesn't set it or uses any other target than the
> default (or hotspot or jdk_only in case of alternative VMs).
>
> Minor nit (please feel free to ignore). The reason text is a little
> misleading, it should say something like:
> REASON = "This JDK does not support SDT probes yet"
> Whether you then use them with Systemtap (or GDB or some other tool that
> can use them) seems irrelevant. (aka, it isn't hotspot supporting
> Systemtap, it is Systemtap supporting DTrace compatible SDT probes).
>
>> Please review and try the patch in this webrev.
>>
>> http://cr.openjdk.java.net/~coleenp/7170638_3/
>> <http://cr.openjdk.java.net/%7Ecoleenp/7170638_3/>
>
> It doesn't seem to work for me. The conditional ifndef OPENJDK seems to
> always evaluate to true in my setup.
>
> Can you explain the OPENJDK=true setting a bit more? I don't see it
> mentioned at:
> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#variables
>
> I do see a Build Directives: OPENJDK = true in my build logs, but that
> is not passed down to any subdir makes. Maybe it should be part of
> COMMON_BUILD_ARGUMENTS in make/Defs-internal.gmk? Or maybe the hotspot
> subdir make should call the sanity target first like the jdk subdir
> does?
>
> It does work for me if I change the conditional to
> ifeq ($(OPENJDK),false). But I don't know if that is what you want.

If OPENJDK is set it should only ever be set to true. The 
jdk/make/common/Defs.gmk file (as used by the top-level build) will set 
it to true if the closed sources are not found:

# If CLOSE_SRC_INCLUDED isn't set to true, check if there's any
# closed directory.
ifneq ($(CLOSED_SRC_INCLUDED), true)
   CLOSED_SRC_INCLUDED := $(shell \
     if [ -d $(CLOSED_SRC) ] ; then \
       echo true; \
     else \
       echo false; \
     fi)
endif

# Set OPENJDK based on CLOSED_SRC_INCLUDED
ifeq ($(CLOSED_SRC_INCLUDED), false)
   OPENJDK = true
endif

Hotspot will default to a non-OPENJDK build unless OPENJDK has been set 
to true, but that only potentially changes the set of sources that will 
be built - if you don't have src/closed or make/closed repos then there 
is no difference between the two builds. Unfortunately Coleen's change 
in dtrace.make requires that OPENJDK be explicitly set to enable the SDT 
probes.

David
-----


>> Also is it possible for the test to do more than just test that the
>> probes are enabled?  Or does it require some external tools?
>
> That would require external tools (in this case I even was careful to
> not use any newer feature of readelf, since only newer versions know how
> to parse the ELF note section to parse out the probes). Given what a
> nightmare it has been to just get a simple build fix in, I rather not
> also try to push any new runtime features or new external tool
> requirements :)
>
> Thanks,
>
> Mark

From mjw at redhat.com  Wed Oct  3 05:48:30 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Wed, 03 Oct 2012 14:48:30 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506C2D25.9020701@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
Message-ID: <1349268510.2682.180.camel@springer.wildebeest.org>

On Wed, 2012-10-03 at 22:18 +1000, David Holmes wrote:
> If OPENJDK is set it should only ever be set to true. The 
> jdk/make/common/Defs.gmk file (as used by the top-level build) will set 
> it to true if the closed sources are not found:
>  [...]
> Hotspot will default to a non-OPENJDK build unless OPENJDK has been set 
> to true, but that only potentially changes the set of sources that will 
> be built - if you don't have src/closed or make/closed repos then there 
> is no difference between the two builds. Unfortunately Coleen's change 
> in dtrace.make requires that OPENJDK be explicitly set to enable the SDT 
> probes.

Aha. So the jdk tree and the hotspot tree don't use the same default
value for OPENJDK if not set. That explains why the builds seemed to
work fine for the jdk part (where OPENJDK is defined to true by
default), but doesn't for the hotspot part (where OPENJDK isn't defined
by default). So if the build for hotspot can be changed to the same as
the jdk tree default with OPENJDK=true then I think Coleen's change is
fine.

But I am not entirely sure where exactly the correct spot in the
toplevel/hotspot make files is to set it.

Thanks,

Mark

From david.holmes at oracle.com  Wed Oct  3 06:00:54 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 03 Oct 2012 23:00:54 +1000
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349268510.2682.180.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
Message-ID: <506C3706.90802@oracle.com>

On 3/10/2012 10:48 PM, Mark Wielaard wrote:
> On Wed, 2012-10-03 at 22:18 +1000, David Holmes wrote:
>> If OPENJDK is set it should only ever be set to true. The
>> jdk/make/common/Defs.gmk file (as used by the top-level build) will set
>> it to true if the closed sources are not found:
>>   [...]
>> Hotspot will default to a non-OPENJDK build unless OPENJDK has been set
>> to true, but that only potentially changes the set of sources that will
>> be built - if you don't have src/closed or make/closed repos then there
>> is no difference between the two builds. Unfortunately Coleen's change
>> in dtrace.make requires that OPENJDK be explicitly set to enable the SDT
>> probes.
>
> Aha. So the jdk tree and the hotspot tree don't use the same default
> value for OPENJDK if not set. That explains why the builds seemed to
> work fine for the jdk part (where OPENJDK is defined to true by
> default), but doesn't for the hotspot part (where OPENJDK isn't defined
> by default).

To be clear, when hotspot is built as part of a full build then it 
should be being passed the OPENJDK variable. But I don't think it is, 
which is a bug in the top-level make logic. It has been a harmless bug 
to-date because, as I said, even if OPENJDK were not set, the absence of 
the closed repos would cause hotspot to be built the same as-if OPENJDK 
had been set,

> So if the build for hotspot can be changed to the same as
> the jdk tree default with OPENJDK=true then I think Coleen's change is
> fine.
>
> But I am not entirely sure where exactly the correct spot in the
> toplevel/hotspot make files is to set it.

Well in the new build system it is all be part of the "configuration" 
and the problem doesn't exist.

To allow for the old build system, and for standalone builds within that 
system, I think the hotspot/make/defs.make would have to duplicate the 
logic that is in jdk/make/common/Defs.gmk.

Otherwise you need to set OPENJDK=true explicitly in your make 
environment when doing a build.

David


> Thanks,
>
> Mark

From mjw at redhat.com  Wed Oct  3 07:38:08 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Wed, 03 Oct 2012 16:38:08 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506C3706.90802@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
Message-ID: <1349275088.2682.200.camel@springer.wildebeest.org>

On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
> To be clear, when hotspot is built as part of a full build then it 
> should be being passed the OPENJDK variable. But I don't think it is, 
> which is a bug in the top-level make logic. It has been a harmless bug 
> to-date

Yeah, it looks like it might have been the intention to pass it down
through COMMON_BUILD_ARGUMENTS?

> To allow for the old build system, and for standalone builds within that 
> system, I think the hotspot/make/defs.make would have to duplicate the 
> logic that is in jdk/make/common/Defs.gmk.

I looked at that, but the build makefile setups are pretty different.
The simplest seems to be to at least add it to the
COMMON_BUILD_ARGUMENTS at the top-level like so:

--- openjdk/make/Defs-internal.gmk.orig	2012-10-03 16:08:00.239767294 +0200
+++ openjdk/make/Defs-internal.gmk	2012-10-03 16:07:50.508629201 +0200
@@ -325,6 +325,10 @@
     PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
     STATIC_CXX=$(STATIC_CXX)
 
+ifdef OPENJDK
+  COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
+endif
+
 ifdef ARCH_DATA_MODEL
   COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
 endif

That works for my setup and should cover most default builds of openjdk
starting from the top-level. Does that look OK to you?

Next we have to figure out how to get the default for OPENJDK set to
true in a plain hotspot dir. But the logic seems to be somewhat
different from what the jdk dir does. We might be able to use the
openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
executed when the the hotspot build detects that it doesn't have
"closed" components. But I am not entirely sure how to satisfy the
restriction listed there:
# This file format must remain compatible with both
# GNU Makefile and Microsoft nmake formats.
Since I don't know anything about nmake.

Cheers,

Mark

From John.Coomes at oracle.com  Wed Oct  3 10:32:33 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Wed, 3 Oct 2012 10:32:33 -0700
Subject: Result: New hsx Committer: Kelly O'Hair
Message-ID: <20588.30385.94373.187475@oracle.com>

Voting for Kelly O'Hair [1] is now closed.

Yes: 18
Veto: 0
Abstain: 0

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

-John

[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006612.html

From karen.kinnear at oracle.com  Wed Oct  3 10:48:10 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 3 Oct 2012 13:48:10 -0400
Subject: Code review request: 7199092 NMT: NMT needs to deal overlapped
	virtual memory ranges
In-Reply-To: <50660A67.1010901@oracle.com>
References: <50660A67.1010901@oracle.com>
Message-ID: <A2FFCBA8-CA8F-4D64-A5E4-06206D7D1934@oracle.com>

Zhengyu,

Great job on fixing this complex virtual memory tracking.

Couple of questions/comments.

1. allocation.hpp
Could you possibly add a comment that Number of memory types does not include mtNone
( or change it so that it does if it needs to)

2. os_solaris.cpp
I can't get to a current repository right this instant - so do you have the same code for
windows and linux and bsd?

3. memBaseline.cpp baseline_malloc_details
Could you possibly add a comment when you sort by callsite pc order or
sort by address order - as to why you need that specific order for the
operation coming up?
And for example for baseline_vm_details could you add a comment in front of
the header specifying that you assume this is sorted in address order.

Lines 317-325: I was not sure why you were incrementing both reserved and
commited for each callsite: didn't you split the records into separate committed and
reserved records?

4. memSnapshot.cpp
split_reserved_region
The way I read reduce_region, you pass it the address and size of the excluded area, not of
the area you have left. Or did I read this incorrectly?

So line 231 wants to have the first argument be: new_rgn_addr and the second argument be
new_rgn_size (actually like the correct line 235)

And line 232 would create the new region using the same logic as line 236, i.e. create
the new region with the new_rgn_addr and new_rgn_size.
I don't think you need to calculate sz here.

So I think both cases need the same logic:
reduce_region(new_rgn_addr, new_rgn_size)
next_rgn(new_rgn_addr, flags, new_rgn_size, pc)
return insert
line 239: "splitted" -> "split"
The rest of the logic looks good.


5. memSnapshot.cpp
reserve_region:

It appears that VMMemRegion contains both reserved and committed regions.
Are they inserted as they are allocated or is there any attempt at
ordering the address ranges (I think no ordering  - right?)

So I was expecting reserve_region to iterate through all the
VMMemRegions and
 1) ignores committed regions and 
 2) checks all of them for duplicate records and
 3) checks all for overlapping reserved records
and then calls insert_record(rec).

And I expected commit_region to iterate through all the
VMMemRegions and
1) check for duplicate commit records (you do)
2) check that there is a reserved region spanning the committed region
(I think that is what lines 95-96 are doing - but they should do that
for all reserved regions, to make sure there is at least one reserved
region that contains the committed region)
-- so perhaps remove lines 95-96 and change the loop to
make sure there is one and the rest looks good
3) then do the expand or insertion (which you do)

So in both reserve_region and commit_region there is an assertion
that (VMMemRegion*)current() is a reserved region. Why is that always true?

What does line 126 do? I was hoping it would remove next_reg - does it?

And is there a check for partial overlap of a committed region and a reserved region?

line 149: "must due" -> "must be due"

6. memSnapshot.cpp
Can you fix "lived" to "live" on line 440 

7. memSnapshot.hpp locate
Did you change the meaning of locate?
It used to either return contains or return the next larger address so you
would insert before it.
It appears to now actually return contains - or null - or did I misread it?

thanks,
Karen


On Sep 28, 2012, at 4:36 PM, Zhengyu Gu wrote:

> With PermGen removal integration, virtual memory usage patterns have changed vs. earlier. NMT can not longer just track reserved memory regions, and assume commits and uncommits are performed from the tail end.
> 
> NMT now tracks committed memory regions, alone with reserved memory regions, a virtual memory map is maintained by NMT, and it is reported with detail tracking data.
> 
> The changes also include some cleanup and enhanced assertion, etc.
> 
> CR: http://bugs.sun.com/view_bug.do?bug_id=7199092
> Webrev:  http://cr.openjdk.java.net/~zgu/7199092/webrev.00/
> 
> 
> An example of virtual memory map:
> 
> Virtual memory map:
> 
> [0x8f17e000 - 0x8f364000] reserved 1944KB for Thread Stack
>        from [Thread::record_stack_base_and_size()+0x120]
>    [0x8f17e000 - 0x8f364000] committed 1944KB from [Thread::record_stack_base_and_size()+0x120]
> 
> [0x8f389000 - 0x8f680000] reserved 3036KB for Thread Stack
>        from [Thread::record_stack_base_and_size()+0x120]
>    [0x8f389000 - 0x8f680000] committed 3036KB from [Thread::record_stack_base_and_size()+0x120]
> 
> [0x8f7dd000 - 0x8f900000] reserved 1164KB for Thread Stack
>        from [Thread::record_stack_base_and_size()+0x120]
>    [0x8f7dd000 - 0x8f900000] committed 1164KB from [Thread::record_stack_base_and_size()+0x120]
> 
> [0x8fa20000 - 0x8faa1000] reserved 516KB for Thread Stack
>        from [Thread::record_stack_base_and_size()+0x120]
>    [0x8fa20000 - 0x8faa1000] committed 516KB from [Thread::record_stack_base_and_size()+0x120]
> 
> [0x8fd30000 - 0x914b8000] reserved 24096KB for GC
>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>    [0x8fd30000 - 0x914b8000] committed 24096KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
> 
> [0x914b8000 - 0x916bc000] reserved 2064KB for Thread Stack
>        from [Thread::record_stack_base_and_size()+0x120]
>    [0x914b8000 - 0x916bc000] committed 2064KB from [Thread::record_stack_base_and_size()+0x120]
> 
> [0x916bc000 - 0x91860000] reserved 1680KB for GC
>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>    [0x916bc000 - 0x916c7000] committed 44KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>    [0x91764000 - 0x9176f000] committed 44KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>    [0x9180b000 - 0x91811000] committed 24KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>    [0x9185f000 - 0x91860000] committed 4KB from [CardTableModRefBS::CardTableModRefBS(MemRegion, int)+0x2a0]
> 
> [0x91860000 - 0xb1060000] reserved 516096KB for Java Heap
>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x190]
>    [0x91860000 - 0x92d50000] committed 21440KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>    [0xa6710000 - 0xa7180000] committed 10688KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>    [0xb0e60000 - 0xb0ea9000] committed 292KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
> 
> [0xb1069000 - 0xb71e9000] reserved 99840KB for Code
>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>    [0xb1069000 - 0xb1072000] committed 36KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>    [0xb11e9000 - 0xb1429000] committed 2304KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
> 
> [0xb71e9000 - 0xb77e9000] reserved 6144KB for Class
>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>    [0xb71e9000 - 0xb750a000] committed 3204KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
> 
> [0xb77e9000 - 0xb783a000] reserved 324KB for Thread Stack
>        from [Thread::record_stack_base_and_size()+0x120]
>    [0xb77e9000 - 0xb783a000] committed 324KB from [Thread::record_stack_base_and_size()+0x120]
> 
> Tests performed:
> - JPRT tests
> 
> - Linux 32 bit:
>    vm.quick.testlist
>    nsk.stress
>    runtime.ParallelClassLoading
>    nsk.quick-jdi.testlist
>    nsk.quick-jvmti.testlist
> 
> - Solaris x64
>    vm.quick.testlist
>    runtime.ParallelClassLoading
>    nsk.stress.jck60
> 
> - Solaris sparcv9
>    vm.quick.testlist
>    runtime.ParallelClassLoading
>    nsk.stress.jck60
> 
> 
> Thanks,
> 
> -Zhengyu


From zhengyu.gu at oracle.com  Wed Oct  3 12:15:19 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Wed, 03 Oct 2012 15:15:19 -0400
Subject: Code review request: 7199092 NMT: NMT needs to deal overlapped
	virtual memory ranges
In-Reply-To: <A2FFCBA8-CA8F-4D64-A5E4-06206D7D1934@oracle.com>
References: <50660A67.1010901@oracle.com>
	<A2FFCBA8-CA8F-4D64-A5E4-06206D7D1934@oracle.com>
Message-ID: <506C8EC7.2020307@oracle.com>

Karen,

Thanks for reviewing. See comments inline.

On 10/3/2012 1:48 PM, Karen Kinnear wrote:
> Zhengyu,
>
> Great job on fixing this complex virtual memory tracking.
>
> Couple of questions/comments.
>
> 1. allocation.hpp
> Could you possibly add a comment that Number of memory types does not include mtNone
> ( or change it so that it does if it needs to)
>
Actually, it does not include mtDontTrack. I moved mt_number_of_types 
ahead of mtDontTrack, and added comment - mtDontTrack is not included as 
validate memory type

> 2. os_solaris.cpp
> I can't get to a current repository right this instant - so do you have the same code for
> windows and linux and bsd?
This is solaris specific problem. Other unix uses platform specific 
anon_mmap() to reserve memory, and also uses plafrom specific 
anon_munmap() to release memory if requested memory region can not be 
acquired. Somehow, there is not solaris specific anon_munmap() 
implementation. Instead, it calls back to os::unmap_memory(), which will 
create 'release' and this is the record with corresponding 'reserve' record.

> 3. memBaseline.cpp baseline_malloc_details
> Could you possibly add a comment when you sort by callsite pc order or
> sort by address order - as to why you need that specific order for the
> operation coming up?
> And for example for baseline_vm_details could you add a comment in front of
> the header specifying thacppt you assume this is sorted in address order.
Comment added
> Lines 317-325: I was not sure why you were incrementing both reserved and
> commited for each callsite: didn't you split the records into separate committed and
> reserved records?
>
VMMemRegion records keep either reserved or committed information, but 
they are aggregated to VMCallsitePointer records, which represents a 
reserved memory region and committed memory size within this region, and 
this region is reserved from a specific callsite.
Lines 317-325  sums up VMCallsitePointer records with the same callsite.
> 4. memSnapshot.cpp
> split_reserved_region
> The way I read reduce_region, you pass it the address and size of the excluded area, not of
> the area you have left. Or did I read this incorrectly?
>
Correct, it is documented in memPtr.hpp VMMemRegion::reduce_region()

   // reduce a memory region to exclude the specified address range.
   // The excluded memory range has to be on either end of this memory
   // region.

> So line 231 wants to have the first argument be: new_rgn_addr and the second argument be
> new_rgn_size (actually like the correct line 235)
>
No. The code is correct. This section deals with the new region is at 
the beginning of the bigger region.
Line 231 reduce original region (bigger region) to this new region, so 
it excludes the upper bound of the
new region (new_rgn_addr + new_rgn_size)  with size = bigger region size 
- new region size.

> And line 232 would create the new region using the same logic as line 236, i.e. create
> the new region with the new_rgn_addr and new_rgn_size.
> I don't think you need to calculate sz here.
>
A bit confusing ... the original region became 'new region'. Here, we 
actually create remaining region.

> So I think both cases need the same logic:
> reduce_region(new_rgn_addr, new_rgn_size)
> next_rgn(new_rgn_addr, flags, new_rgn_size, pc)
> return insert

> line 239: "splitted" ->  "split"
> The rest of the logic looks good.
Fixed

> 5. memSnapshot.cpp
> reserve_region:
>
> It appears that VMMemRegion contains both reserved and committed regions.
> Are they inserted as they are allocated or is there any attempt at
> ordering the address ranges (I think no ordering  - right?)
>
No. VMMemRegion represents either reserved, or committed region.

virtual memory regions are maintained in memory's base address order.
> So I was expecting reserve_region to iterate through all the
> VMMemRegions and

>   1) ignores committed regions and
VMMemPointerIterator::locate() does this

>   2) checks all of them for duplicate records and
Line 71
>   3) checks all for overlapping reserved records
> and then calls insert_record(rec).
Also, no overlapping reserved regions allowed (if there is, regions are 
already split)

> And I expected commit_region to iterate through all the
> VMMemRegions and
> 1) check for duplicate commit records (you do)
> 2) check that there is a reserved region spanning the committed region
> (I think that is what lines 95-96 are doing - but they should do that
> for all reserved regions, to make sure there is at least one reserved
> region that contains the committed region)
> -- so perhaps remove lines 95-96 and change the loop to
> make sure there is one and the rest looks good
> 3) then do the expand or insertion (which you do)
>
> So in both reserve_region and commit_region there is an assertion
> that (VMMemRegion*)current() is a reserved region. Why is that always true?
>
VMMemPointerIterator::locate() only locates 'reserved' records.

> What does line 126 do? I was hoping it would remove next_reg - does it?
Yes.
> And is there a check for partial overlap of a committed region and a reserved region?
>
> line 149: "must due" ->  "must be due"
>
Fixed
> 6. memSnapshot.cpp
> Can you fix "lived" to "live" on line 440
>
Fixed

> 7. memSnapshot.hpp locate
> Did you change the meaning of locate?
> It used to either return contains or return the next larger address so you
> would insert before it.
> It appears to now actually return contains - or null - or did I misread it?
>
Which one you talk about? VMMemPointerIterator::locate()? it return a 
reserved region that contains the specified memory range, or the 
position nearest to it.

Thanks,

-Zhengyu

> thanks,
> Karen
>
>
> On Sep 28, 2012, at 4:36 PM, Zhengyu Gu wrote:
>
>> With PermGen removal integration, virtual memory usage patterns have changed vs. earlier. NMT can not longer just track reserved memory regions, and assume commits and uncommits are performed from the tail end.
>>
>> NMT now tracks committed memory regions, alone with reserved memory regions, a virtual memory map is maintained by NMT, and it is reported with detail tracking data.
>>
>> The changes also include some cleanup and enhanced assertion, etc.
>>
>> CR: http://bugs.sun.com/view_bug.do?bug_id=7199092
>> Webrev:  http://cr.openjdk.java.net/~zgu/7199092/webrev.00/
>>
>>
>> An example of virtual memory map:
>>
>> Virtual memory map:
>>
>> [0x8f17e000 - 0x8f364000] reserved 1944KB for Thread Stack
>>         from [Thread::record_stack_base_and_size()+0x120]
>>     [0x8f17e000 - 0x8f364000] committed 1944KB from [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8f389000 - 0x8f680000] reserved 3036KB for Thread Stack
>>         from [Thread::record_stack_base_and_size()+0x120]
>>     [0x8f389000 - 0x8f680000] committed 3036KB from [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8f7dd000 - 0x8f900000] reserved 1164KB for Thread Stack
>>         from [Thread::record_stack_base_and_size()+0x120]
>>     [0x8f7dd000 - 0x8f900000] committed 1164KB from [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8fa20000 - 0x8faa1000] reserved 516KB for Thread Stack
>>         from [Thread::record_stack_base_and_size()+0x120]
>>     [0x8fa20000 - 0x8faa1000] committed 516KB from [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8fd30000 - 0x914b8000] reserved 24096KB for GC
>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>     [0x8fd30000 - 0x914b8000] committed 24096KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>
>> [0x914b8000 - 0x916bc000] reserved 2064KB for Thread Stack
>>         from [Thread::record_stack_base_and_size()+0x120]
>>     [0x914b8000 - 0x916bc000] committed 2064KB from [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x916bc000 - 0x91860000] reserved 1680KB for GC
>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>     [0x916bc000 - 0x916c7000] committed 44KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>     [0x91764000 - 0x9176f000] committed 44KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>>     [0x9180b000 - 0x91811000] committed 24KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>>     [0x9185f000 - 0x91860000] committed 4KB from [CardTableModRefBS::CardTableModRefBS(MemRegion, int)+0x2a0]
>>
>> [0x91860000 - 0xb1060000] reserved 516096KB for Java Heap
>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x190]
>>     [0x91860000 - 0x92d50000] committed 21440KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>     [0xa6710000 - 0xa7180000] committed 10688KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>     [0xb0e60000 - 0xb0ea9000] committed 292KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>
>> [0xb1069000 - 0xb71e9000] reserved 99840KB for Code
>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>     [0xb1069000 - 0xb1072000] committed 36KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>     [0xb11e9000 - 0xb1429000] committed 2304KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>
>> [0xb71e9000 - 0xb77e9000] reserved 6144KB for Class
>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>     [0xb71e9000 - 0xb750a000] committed 3204KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>
>> [0xb77e9000 - 0xb783a000] reserved 324KB for Thread Stack
>>         from [Thread::record_stack_base_and_size()+0x120]
>>     [0xb77e9000 - 0xb783a000] committed 324KB from [Thread::record_stack_base_and_size()+0x120]
>>
>> Tests performed:
>> - JPRT tests
>>
>> - Linux 32 bit:
>>     vm.quick.testlist
>>     nsk.stress
>>     runtime.ParallelClassLoading
>>     nsk.quick-jdi.testlist
>>     nsk.quick-jvmti.testlist
>>
>> - Solaris x64
>>     vm.quick.testlist
>>     runtime.ParallelClassLoading
>>     nsk.stress.jck60
>>
>> - Solaris sparcv9
>>     vm.quick.testlist
>>     runtime.ParallelClassLoading
>>     nsk.stress.jck60
>>
>>
>> Thanks,
>>
>> -Zhengyu

From coleen.phillimore at oracle.com  Wed Oct  3 14:52:34 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 03 Oct 2012 17:52:34 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349275088.2682.200.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
Message-ID: <506CB3A2.7090208@oracle.com>


The logic for setting up OPENJDK is different but there was some code to 
set up HOTSPOT_VM_DISTRO based on the presence or absence of certain 
closed files.   Anyway, I think this code is correct now.   It sets 
OPENJDK if HOTSPOT_VM_DISTRO is OpenJDK.   I can build Hotspot on Linux 
both ways now.

open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638

I also filed a bug 8000408 for Oracle JVM to support this in the future.

Please review, again, and thank you for your patience!

Coleen

On 10/3/2012 10:38 AM, Mark Wielaard wrote:
> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>> To be clear, when hotspot is built as part of a full build then it
>> should be being passed the OPENJDK variable. But I don't think it is,
>> which is a bug in the top-level make logic. It has been a harmless bug
>> to-date
> Yeah, it looks like it might have been the intention to pass it down
> through COMMON_BUILD_ARGUMENTS?
>
>> To allow for the old build system, and for standalone builds within that
>> system, I think the hotspot/make/defs.make would have to duplicate the
>> logic that is in jdk/make/common/Defs.gmk.
> I looked at that, but the build makefile setups are pretty different.
> The simplest seems to be to at least add it to the
> COMMON_BUILD_ARGUMENTS at the top-level like so:
>
> --- openjdk/make/Defs-internal.gmk.orig	2012-10-03 16:08:00.239767294 +0200
> +++ openjdk/make/Defs-internal.gmk	2012-10-03 16:07:50.508629201 +0200
> @@ -325,6 +325,10 @@
>       PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>       STATIC_CXX=$(STATIC_CXX)
>
> +ifdef OPENJDK
> +  COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
> +endif
> +
>   ifdef ARCH_DATA_MODEL
>     COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>   endif
>
> That works for my setup and should cover most default builds of openjdk
> starting from the top-level. Does that look OK to you?
>
> Next we have to figure out how to get the default for OPENJDK set to
> true in a plain hotspot dir. But the logic seems to be somewhat
> different from what the jdk dir does. We might be able to use the
> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
> executed when the the hotspot build detects that it doesn't have
> "closed" components. But I am not entirely sure how to satisfy the
> restriction listed there:
> # This file format must remain compatible with both
> # GNU Makefile and Microsoft nmake formats.
> Since I don't know anything about nmake.
>
> Cheers,
>
> Mark

From david.holmes at oracle.com  Wed Oct  3 16:01:47 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 09:01:47 +1000
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506CB3A2.7090208@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com>
Message-ID: <506CC3DB.3050104@oracle.com>

Coleen,

On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>
> The logic for setting up OPENJDK is different but there was some code to
> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
> closed files. Anyway, I think this code is correct now. It sets OPENJDK
> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux both ways
> now.

Sorry but that is the wrong fix. If anything OPENJDK should be 
controlling which distro file gets included. The logic for that in 
buildtree.make is:

ifndef HOTSPOT_VM_DISTRO
   ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
     include $(GAMMADIR)/make/hotspot_distro
   else
     include $(GAMMADIR)/make/openjdk_distro
   endif
endif

So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true 
setting - and that file is the wrong place to set that variable.

To remedy this in hotspot, for a hotspot-only build, we need to check 
for something that indicates this is not an OPENJDK build. The presence 
of the closed repos is generally what is used for that. But placing such 
a check correctly is extremely awkward (something compounded by the fact 
that present hotspot make/defs.make has a couple of bugs in ordering 
that the minimal VM changes will fix). So right now I can't tell you 
exactly how to fix this in a more suitable way.

David
-----

>
> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>
> I also filed a bug 8000408 for Oracle JVM to support this in the future.
>
> Please review, again, and thank you for your patience!
>
> Coleen
>
> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>> To be clear, when hotspot is built as part of a full build then it
>>> should be being passed the OPENJDK variable. But I don't think it is,
>>> which is a bug in the top-level make logic. It has been a harmless bug
>>> to-date
>> Yeah, it looks like it might have been the intention to pass it down
>> through COMMON_BUILD_ARGUMENTS?
>>
>>> To allow for the old build system, and for standalone builds within that
>>> system, I think the hotspot/make/defs.make would have to duplicate the
>>> logic that is in jdk/make/common/Defs.gmk.
>> I looked at that, but the build makefile setups are pretty different.
>> The simplest seems to be to at least add it to the
>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>
>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03 16:08:00.239767294
>> +0200
>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201 +0200
>> @@ -325,6 +325,10 @@
>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>> STATIC_CXX=$(STATIC_CXX)
>>
>> +ifdef OPENJDK
>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>> +endif
>> +
>> ifdef ARCH_DATA_MODEL
>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>> endif
>>
>> That works for my setup and should cover most default builds of openjdk
>> starting from the top-level. Does that look OK to you?
>>
>> Next we have to figure out how to get the default for OPENJDK set to
>> true in a plain hotspot dir. But the logic seems to be somewhat
>> different from what the jdk dir does. We might be able to use the
>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>> executed when the the hotspot build detects that it doesn't have
>> "closed" components. But I am not entirely sure how to satisfy the
>> restriction listed there:
>> # This file format must remain compatible with both
>> # GNU Makefile and Microsoft nmake formats.
>> Since I don't know anything about nmake.
>>
>> Cheers,
>>
>> Mark

From andreas.eriksson at oracle.com  Thu Oct  4 04:30:05 2012
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Thu, 04 Oct 2012 13:30:05 +0200
Subject: Fwd: Re: Review request (S): 7176220: 'Full GC' events miss date
	stamp information occasionally
In-Reply-To: <506AE1D3.1050103@oracle.com>
References: <506AE1D3.1050103@oracle.com>
Message-ID: <506D733D.10302@oracle.com>

Hi,

Can I have some reviews for the following change please:
http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ 
<http://cr.openjdk.java.net/%7Ebrutisso/7176220/webrev.00/>

See forwarded mails for more info.

Regards,
Andreas


-------- Original Message --------
Subject: 	Re: Review request (S): 7176220: 'Full GC' events miss date 
stamp information occasionally
Date: 	Tue, 02 Oct 2012 14:45:07 +0200
From: 	Bengt Rutisson <bengt.rutisson at oracle.com>
To: 	Andreas Eriksson <andreas.eriksson at oracle.com>
CC: 	hotspot-gc-dev at openjdk.java.net





Hi Andreas,

I think this looks good. I like that we treat PrintGCDateStamps and 
PrintGCTimeStamps in a consistent way.

One thing that kind of worries me is that the TraceTime class is used 
from other parts of the JVM than just the GC. This means that you now 
get date stamps on compiler events if you enable PrintGCDateStamps. I 
think this is probably fine since they already get time stamps if you 
enable PrintGCTimeStamps. See for example how PhaseTraceTime is used in C1.

Maybe we should send this review out on hotspot-dev to make sure that 
all teams have a chance to comment on this?

Thanks,
Bengt

On 2012-09-28 12:01, Andreas Eriksson wrote:
> Hi,
>
> Can I have some reviews for the following change please:
> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ebrutisso/7176220/webrev.00/>
>
> This fixes GC logs from genCollectedHeap.cpp where sometimes it would 
> not print date-stamps.
> The fix moves printing of date-stamps into TraceTime, where 
> time-stamps are already printed from.
>
> Bug with flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -verbose:gc 
> -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps:
> 2012-09-28T11:41:38.687+0200: 0.205: [Full GC 8702K->1012K(9920K), 
> 0.0108630 secs]
> 1.253: [Full GC 3326K->1012K(9920K), 0.0105750 secs]
> 2.299: [Full GC 7932K->1012K(9920K), 0.0100470 secs]
> 2012-09-28T11:41:41.813+0200: 3.331: [Full GC 8702K->1012K(9920K), 
> 0.0103210 secs]
>
> Another route that was investigated was to add the date-stamp call 
> directly in genCollectedHeap.cpp, but because of complex interactions 
> when a full GC was initiated from a non-full GC this path was not taken.
>
>
> This will slightly change the logging output when using 
> -XX:+PrintGCDetails.
> Now date-stamps will also be printed inside other lines, as 
> time-stamps already are:
>
> Before:
> 2012-09-28T11:29:16.815+0200: 0.177: [GC0.177: [ParNew: 
> 2710K->46K(3072K), 0.0053590 secs] 3480K->1835K(9920K), 0.0055500 
> secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
>
> After:
> 2012-09-28T11:29:33.260+0200: 0.184: [GC2012-09-28T11:29:33.261+0200: 
> 0.184: [ParNew: 2642K->45K(3072K), 0.0095770 secs] 
> 3412K->1828K(9920K), 0.0097520 secs] [Times: user=0.01 sys=0.00, 
> real=0.01 secs]
>
> Thanks to Bengt Rutisson for helping with the change and webrev.
>
> Regards,
> Andreas





From coleen.phillimore at oracle.com  Thu Oct  4 04:43:44 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 04 Oct 2012 07:43:44 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506CC3DB.3050104@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
Message-ID: <506D7670.9040103@oracle.com>

On 10/3/2012 7:01 PM, David Holmes wrote:
> Coleen,
>
> On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>>
>> The logic for setting up OPENJDK is different but there was some code to
>> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
>> closed files. Anyway, I think this code is correct now. It sets OPENJDK
>> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux both ways
>> now.
>
> Sorry but that is the wrong fix. If anything OPENJDK should be 
> controlling which distro file gets included. The logic for that in 
> buildtree.make is:
>
> ifndef HOTSPOT_VM_DISTRO
>   ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
>     include $(GAMMADIR)/make/hotspot_distro
>   else
>     include $(GAMMADIR)/make/openjdk_distro
>   endif
> endif
>
> So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true 
> setting - and that file is the wrong place to set that variable.

Actually, if you set HOTSPOT_VM_DISTRO, that implies that you want some 
other distro regardless of whether the Oracle closed repositories 
exist.    So OPENJDK should be false in this case.

i still think this change does exactly what we want.   I tried the 
suggested change you had in defs.make and it was pretty horrible.   This 
checks this same thing more cleanly.

Thanks,
Coleen
>
> To remedy this in hotspot, for a hotspot-only build, we need to check 
> for something that indicates this is not an OPENJDK build. The 
> presence of the closed repos is generally what is used for that. But 
> placing such a check correctly is extremely awkward (something 
> compounded by the fact that present hotspot make/defs.make has a 
> couple of bugs in ordering that the minimal VM changes will fix). So 
> right now I can't tell you exactly how to fix this in a more suitable 
> way.
>
> David
> -----
>
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>>
>> I also filed a bug 8000408 for Oracle JVM to support this in the future.
>>
>> Please review, again, and thank you for your patience!
>>
>> Coleen
>>
>> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>>> To be clear, when hotspot is built as part of a full build then it
>>>> should be being passed the OPENJDK variable. But I don't think it is,
>>>> which is a bug in the top-level make logic. It has been a harmless bug
>>>> to-date
>>> Yeah, it looks like it might have been the intention to pass it down
>>> through COMMON_BUILD_ARGUMENTS?
>>>
>>>> To allow for the old build system, and for standalone builds within 
>>>> that
>>>> system, I think the hotspot/make/defs.make would have to duplicate the
>>>> logic that is in jdk/make/common/Defs.gmk.
>>> I looked at that, but the build makefile setups are pretty different.
>>> The simplest seems to be to at least add it to the
>>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>>
>>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03 16:08:00.239767294
>>> +0200
>>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201 +0200
>>> @@ -325,6 +325,10 @@
>>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>>> STATIC_CXX=$(STATIC_CXX)
>>>
>>> +ifdef OPENJDK
>>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>>> +endif
>>> +
>>> ifdef ARCH_DATA_MODEL
>>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>>> endif
>>>
>>> That works for my setup and should cover most default builds of openjdk
>>> starting from the top-level. Does that look OK to you?
>>>
>>> Next we have to figure out how to get the default for OPENJDK set to
>>> true in a plain hotspot dir. But the logic seems to be somewhat
>>> different from what the jdk dir does. We might be able to use the
>>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>>> executed when the the hotspot build detects that it doesn't have
>>> "closed" components. But I am not entirely sure how to satisfy the
>>> restriction listed there:
>>> # This file format must remain compatible with both
>>> # GNU Makefile and Microsoft nmake formats.
>>> Since I don't know anything about nmake.
>>>
>>> Cheers,
>>>
>>> Mark


From mjw at redhat.com  Thu Oct  4 06:08:20 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Thu, 04 Oct 2012 15:08:20 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506CB3A2.7090208@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com>
Message-ID: <1349356100.2501.8.camel@springer.wildebeest.org>

On Wed, 2012-10-03 at 17:52 -0400, Coleen Phillimore wrote:
> The logic for setting up OPENJDK is different but there was some code to 
> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain 
> closed files.   Anyway, I think this code is correct now.   It sets 
> OPENJDK if HOTSPOT_VM_DISTRO is OpenJDK.   I can build Hotspot on Linux 
> both ways now.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
> 
> I also filed a bug 8000408 for Oracle JVM to support this in the future.
> 
> Please review, again, and thank you for your patience!

Nice, that was a lot easier than I feared. Just one additional line!
I totally missed the flags.make snippet was generated by the buildtree
makefile itself. Works fine here. Thanks.

One small comment. Shouldn't you also make the same change to
make/solaris/makefiles/buildtree.make and
make/bsd/makefiles/buildtree.make to keep them in sync?

Thanks,

Mark

From david.holmes at oracle.com  Thu Oct  4 06:29:55 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 23:29:55 +1000
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506D7670.9040103@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com>
Message-ID: <506D8F53.5010609@oracle.com>

On 4/10/2012 9:43 PM, Coleen Phillimore wrote:
> On 10/3/2012 7:01 PM, David Holmes wrote:
>> Coleen,
>>
>> On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>>>
>>> The logic for setting up OPENJDK is different but there was some code to
>>> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
>>> closed files. Anyway, I think this code is correct now. It sets OPENJDK
>>> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux both ways
>>> now.
>>
>> Sorry but that is the wrong fix. If anything OPENJDK should be
>> controlling which distro file gets included. The logic for that in
>> buildtree.make is:
>>
>> ifndef HOTSPOT_VM_DISTRO
>> ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
>> include $(GAMMADIR)/make/hotspot_distro
>> else
>> include $(GAMMADIR)/make/openjdk_distro
>> endif
>> endif
>>
>> So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true
>> setting - and that file is the wrong place to set that variable.
>
> Actually, if you set HOTSPOT_VM_DISTRO, that implies that you want some
> other distro regardless of whether the Oracle closed repositories exist.
> So OPENJDK should be false in this case.

HOTSPOT_VM_DISTRO just gives a name to the distro. It can still be 
OpenJDK, or more to the point it will fail to build if not treated as 
OPENJDK when built externally.

Further the logic that chooses to include hotspot_distro or 
openjdk_distro uses the altsrc macros, but they are in turn defined 
depending on whether OPENJDK is true or not. So there seems to be a 
circular dependency there.

> i still think this change does exactly what we want. I tried the
> suggested change you had in defs.make and it was pretty horrible. This
> checks this same thing more cleanly.

I've sent a more detailed suggestion offline. This whole situation is a 
complete mess (and nothing directly to do with this specific bug fix).

Thanks,
David
-----

> Thanks,
> Coleen
>>
>> To remedy this in hotspot, for a hotspot-only build, we need to check
>> for something that indicates this is not an OPENJDK build. The
>> presence of the closed repos is generally what is used for that. But
>> placing such a check correctly is extremely awkward (something
>> compounded by the fact that present hotspot make/defs.make has a
>> couple of bugs in ordering that the minimal VM changes will fix). So
>> right now I can't tell you exactly how to fix this in a more suitable
>> way.
>>
>> David
>> -----
>>
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>>>
>>> I also filed a bug 8000408 for Oracle JVM to support this in the future.
>>>
>>> Please review, again, and thank you for your patience!
>>>
>>> Coleen
>>>
>>> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>>>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>>>> To be clear, when hotspot is built as part of a full build then it
>>>>> should be being passed the OPENJDK variable. But I don't think it is,
>>>>> which is a bug in the top-level make logic. It has been a harmless bug
>>>>> to-date
>>>> Yeah, it looks like it might have been the intention to pass it down
>>>> through COMMON_BUILD_ARGUMENTS?
>>>>
>>>>> To allow for the old build system, and for standalone builds within
>>>>> that
>>>>> system, I think the hotspot/make/defs.make would have to duplicate the
>>>>> logic that is in jdk/make/common/Defs.gmk.
>>>> I looked at that, but the build makefile setups are pretty different.
>>>> The simplest seems to be to at least add it to the
>>>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>>>
>>>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03 16:08:00.239767294
>>>> +0200
>>>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201 +0200
>>>> @@ -325,6 +325,10 @@
>>>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>>>> STATIC_CXX=$(STATIC_CXX)
>>>>
>>>> +ifdef OPENJDK
>>>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>>>> +endif
>>>> +
>>>> ifdef ARCH_DATA_MODEL
>>>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>>>> endif
>>>>
>>>> That works for my setup and should cover most default builds of openjdk
>>>> starting from the top-level. Does that look OK to you?
>>>>
>>>> Next we have to figure out how to get the default for OPENJDK set to
>>>> true in a plain hotspot dir. But the logic seems to be somewhat
>>>> different from what the jdk dir does. We might be able to use the
>>>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>>>> executed when the the hotspot build detects that it doesn't have
>>>> "closed" components. But I am not entirely sure how to satisfy the
>>>> restriction listed there:
>>>> # This file format must remain compatible with both
>>>> # GNU Makefile and Microsoft nmake formats.
>>>> Since I don't know anything about nmake.
>>>>
>>>> Cheers,
>>>>
>>>> Mark
>

From david.holmes at oracle.com  Thu Oct  4 07:00:11 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Oct 2012 00:00:11 +1000
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506D8F53.5010609@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
Message-ID: <506D966B.1040406@oracle.com>

For the record, the suggested fix to defs.make doesn't presently work 
because defs.make isn't seen by all makefiles used by the various 
sub-makes. But that will change with the changes coming as part of the 
minimal VM work.

Coleen's fix seemed to have a circular dependency, but thinking more it 
is only partially circular - if that makes sense :) The default path for 
altsrc depends on whether OPENJDK is true or not, but the actual 
existence check will still work. So if OPENJDK is not set we will look 
for src/closed, and if that exists then we are not an OPENJDK build - 
else if it does not exist we can simply set OPENJDK=true (no need to do 
it in the distro file - as Coleen has pointed out offline). Had OPENJDK 
been set to true initially we would have looked for a different altsrc 
but it still would not exist so we'd execute the same logic that would 
(redundantly) set OPENJDK to true again.

We will need to fix the top-level build regardless, so that it passes 
down OPENJDK=true.

David (signing off for the night)
-----

On 4/10/2012 11:29 PM, David Holmes wrote:
> On 4/10/2012 9:43 PM, Coleen Phillimore wrote:
>> On 10/3/2012 7:01 PM, David Holmes wrote:
>>> Coleen,
>>>
>>> On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>>>>
>>>> The logic for setting up OPENJDK is different but there was some
>>>> code to
>>>> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
>>>> closed files. Anyway, I think this code is correct now. It sets OPENJDK
>>>> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux both ways
>>>> now.
>>>
>>> Sorry but that is the wrong fix. If anything OPENJDK should be
>>> controlling which distro file gets included. The logic for that in
>>> buildtree.make is:
>>>
>>> ifndef HOTSPOT_VM_DISTRO
>>> ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
>>> include $(GAMMADIR)/make/hotspot_distro
>>> else
>>> include $(GAMMADIR)/make/openjdk_distro
>>> endif
>>> endif
>>>
>>> So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true
>>> setting - and that file is the wrong place to set that variable.
>>
>> Actually, if you set HOTSPOT_VM_DISTRO, that implies that you want some
>> other distro regardless of whether the Oracle closed repositories exist.
>> So OPENJDK should be false in this case.
>
> HOTSPOT_VM_DISTRO just gives a name to the distro. It can still be
> OpenJDK, or more to the point it will fail to build if not treated as
> OPENJDK when built externally.
>
> Further the logic that chooses to include hotspot_distro or
> openjdk_distro uses the altsrc macros, but they are in turn defined
> depending on whether OPENJDK is true or not. So there seems to be a
> circular dependency there.
>
>> i still think this change does exactly what we want. I tried the
>> suggested change you had in defs.make and it was pretty horrible. This
>> checks this same thing more cleanly.
>
> I've sent a more detailed suggestion offline. This whole situation is a
> complete mess (and nothing directly to do with this specific bug fix).
>
> Thanks,
> David
> -----
>
>> Thanks,
>> Coleen
>>>
>>> To remedy this in hotspot, for a hotspot-only build, we need to check
>>> for something that indicates this is not an OPENJDK build. The
>>> presence of the closed repos is generally what is used for that. But
>>> placing such a check correctly is extremely awkward (something
>>> compounded by the fact that present hotspot make/defs.make has a
>>> couple of bugs in ordering that the minimal VM changes will fix). So
>>> right now I can't tell you exactly how to fix this in a more suitable
>>> way.
>>>
>>> David
>>> -----
>>>
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>>>>
>>>> I also filed a bug 8000408 for Oracle JVM to support this in the
>>>> future.
>>>>
>>>> Please review, again, and thank you for your patience!
>>>>
>>>> Coleen
>>>>
>>>> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>>>>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>>>>> To be clear, when hotspot is built as part of a full build then it
>>>>>> should be being passed the OPENJDK variable. But I don't think it is,
>>>>>> which is a bug in the top-level make logic. It has been a harmless
>>>>>> bug
>>>>>> to-date
>>>>> Yeah, it looks like it might have been the intention to pass it down
>>>>> through COMMON_BUILD_ARGUMENTS?
>>>>>
>>>>>> To allow for the old build system, and for standalone builds within
>>>>>> that
>>>>>> system, I think the hotspot/make/defs.make would have to duplicate
>>>>>> the
>>>>>> logic that is in jdk/make/common/Defs.gmk.
>>>>> I looked at that, but the build makefile setups are pretty different.
>>>>> The simplest seems to be to at least add it to the
>>>>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>>>>
>>>>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03 16:08:00.239767294
>>>>> +0200
>>>>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201 +0200
>>>>> @@ -325,6 +325,10 @@
>>>>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>>>>> STATIC_CXX=$(STATIC_CXX)
>>>>>
>>>>> +ifdef OPENJDK
>>>>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>>>>> +endif
>>>>> +
>>>>> ifdef ARCH_DATA_MODEL
>>>>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>>>>> endif
>>>>>
>>>>> That works for my setup and should cover most default builds of
>>>>> openjdk
>>>>> starting from the top-level. Does that look OK to you?
>>>>>
>>>>> Next we have to figure out how to get the default for OPENJDK set to
>>>>> true in a plain hotspot dir. But the logic seems to be somewhat
>>>>> different from what the jdk dir does. We might be able to use the
>>>>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>>>>> executed when the the hotspot build detects that it doesn't have
>>>>> "closed" components. But I am not entirely sure how to satisfy the
>>>>> restriction listed there:
>>>>> # This file format must remain compatible with both
>>>>> # GNU Makefile and Microsoft nmake formats.
>>>>> Since I don't know anything about nmake.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mark
>>

From john.cuthbertson at oracle.com  Thu Oct  4 10:28:39 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Oct 2012 10:28:39 -0700
Subject: Fwd: Re: Review request (S): 7176220: 'Full GC' events miss date
	stamp information occasionally
In-Reply-To: <506D733D.10302@oracle.com>
References: <506AE1D3.1050103@oracle.com> <506D733D.10302@oracle.com>
Message-ID: <506DC747.10300@oracle.com>

Hi Andreas,

This looks good to me except I have one question/comment:

In genCollectedHeap.cpp, the old code was:

 386     bool complete = full && (max_level == (n_gens()-1));
 387     const char* gc_cause_prefix = complete ? "Full GC" : "GC";
 388     gclog_or_tty->date_stamp(PrintGC && PrintGCDateStamps);
 389     TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty);
 390     TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), PrintGCDetails, false, gclog_or_tty);

The new code is:

 386     bool complete = full && (max_level == (n_gens()-1));
 387     const char* gc_cause_prefix = complete ? "Full GC" : "GC";
 388     TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty);
 389     TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), PrintGCDetails, false, gclog_or_tty);


In the old code, the date stamp was printed if PrintGC was enabled, but 
the TraceTime::_doit field is set based upon the value of 
PrintGCDetails. Looking at the other instantiations of the TraceTime 
class, this seems inconsistent. I believe that the second parameter to 
the TraceTime constructor should be PrintGC instead of PrintGCDetails.

Regards,

JohnC

On 10/04/12 04:30, Andreas Eriksson wrote:
> Hi,
>
> Can I have some reviews for the following change please:
> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ebrutisso/7176220/webrev.00/>
>
> See forwarded mails for more info.
>
> Regards,
> Andreas
>
>
> -------- Original Message --------
> Subject:     Re: Review request (S): 7176220: 'Full GC' events miss 
> date stamp information occasionally
> Date:     Tue, 02 Oct 2012 14:45:07 +0200
> From:     Bengt Rutisson <bengt.rutisson at oracle.com>
> To:     Andreas Eriksson <andreas.eriksson at oracle.com>
> CC:     hotspot-gc-dev at openjdk.java.net
>
>
>
>
>
> Hi Andreas,
>
> I think this looks good. I like that we treat PrintGCDateStamps and 
> PrintGCTimeStamps in a consistent way.
>
> One thing that kind of worries me is that the TraceTime class is used 
> from other parts of the JVM than just the GC. This means that you now 
> get date stamps on compiler events if you enable PrintGCDateStamps. I 
> think this is probably fine since they already get time stamps if you 
> enable PrintGCTimeStamps. See for example how PhaseTraceTime is used 
> in C1.
>
> Maybe we should send this review out on hotspot-dev to make sure that 
> all teams have a chance to comment on this?
>
> Thanks,
> Bengt
>
> On 2012-09-28 12:01, Andreas Eriksson wrote:
>> Hi,
>>
>> Can I have some reviews for the following change please:
>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ebrutisso/7176220/webrev.00/>
>>
>> This fixes GC logs from genCollectedHeap.cpp where sometimes it would 
>> not print date-stamps.
>> The fix moves printing of date-stamps into TraceTime, where 
>> time-stamps are already printed from.
>>
>> Bug with flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -verbose:gc 
>> -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps:
>> 2012-09-28T11:41:38.687+0200: 0.205: [Full GC 8702K->1012K(9920K), 
>> 0.0108630 secs]
>> 1.253: [Full GC 3326K->1012K(9920K), 0.0105750 secs]
>> 2.299: [Full GC 7932K->1012K(9920K), 0.0100470 secs]
>> 2012-09-28T11:41:41.813+0200: 3.331: [Full GC 8702K->1012K(9920K), 
>> 0.0103210 secs]
>>
>> Another route that was investigated was to add the date-stamp call 
>> directly in genCollectedHeap.cpp, but because of complex interactions 
>> when a full GC was initiated from a non-full GC this path was not taken.
>>
>>
>> This will slightly change the logging output when using 
>> -XX:+PrintGCDetails.
>> Now date-stamps will also be printed inside other lines, as 
>> time-stamps already are:
>>
>> Before:
>> 2012-09-28T11:29:16.815+0200: 0.177: [GC0.177: [ParNew: 
>> 2710K->46K(3072K), 0.0053590 secs] 3480K->1835K(9920K), 0.0055500 
>> secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
>>
>> After:
>> 2012-09-28T11:29:33.260+0200: 0.184: [GC2012-09-28T11:29:33.261+0200: 
>> 0.184: [ParNew: 2642K->45K(3072K), 0.0095770 secs] 
>> 3412K->1828K(9920K), 0.0097520 secs] [Times: user=0.01 sys=0.00, 
>> real=0.01 secs]
>>
>> Thanks to Bengt Rutisson for helping with the change and webrev.
>>
>> Regards,
>> Andreas
>
>
>
>


From mjw at redhat.com  Thu Oct  4 11:48:10 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Thu, 4 Oct 2012 20:48:10 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506D966B.1040406@oracle.com>
References: <1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com>
Message-ID: <20121004184810.GA13773@toonder.wildebeest.org>

On Fri, Oct 05, 2012 at 12:00:11AM +1000, David Holmes wrote:
> We will need to fix the top-level build regardless, so that it
> passes down OPENJDK=true.

I believe the only thing needed for that is the patch I posted in
the other email:

--- openjdk/make/Defs-internal.gmk.orig	2012-10-03 16:08:00.239767294 +0200
+++ openjdk/make/Defs-internal.gmk	2012-10-03 16:07:50.508629201 +0200
@@ -325,6 +325,10 @@
      PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
      STATIC_CXX=$(STATIC_CXX)

+ifdef OPENJDK
+  COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
+endif
+
  ifdef ARCH_DATA_MODEL
    COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
  endif


Cheers,

Mark

From coleen.phillimore at oracle.com  Thu Oct  4 14:30:01 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 04 Oct 2012 17:30:01 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506D966B.1040406@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com>
Message-ID: <506DFFD9.8010902@oracle.com>


I have modified this change in two ways.  Rather than adding setting 
OPENJDK to openjdk_distro, I am setting it after openjdk_distro is 
included if OPENJDK isn't set, which I was the change that David and I 
discussed offline.  It is redundant but not circular and is safe if 
OPENJDK is passed down.    I will file a bug against the JDK build to do 
this in the future, but many of us build only the hotspot repository.

The other change was that dtrace.hpp didn't build on windows.  The linux 
definitions expand to null for windows.

open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/
bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638_5

A couple of comments below.

On 10/4/2012 10:00 AM, David Holmes wrote:
> For the record, the suggested fix to defs.make doesn't presently work 
> because defs.make isn't seen by all makefiles used by the various 
> sub-makes. But that will change with the changes coming as part of the 
> minimal VM work.

Even if this test is included in defs.make and OPENJDK is set, the 
dtrace.make makefile won't get this definition.  It only gets flags in 
flags.make created by buildtree.make.  So I didn't see any reason to 
move this to defs.make.   I had a look at the latest minimal vm changes 
and this doesn't affect that.
>
> Coleen's fix seemed to have a circular dependency, but thinking more 
> it is only partially circular - if that makes sense :) The default 
> path for altsrc depends on whether OPENJDK is true or not, but the 
> actual existence check will still work. So if OPENJDK is not set we 
> will look for src/closed, and if that exists then we are not an 
> OPENJDK build - else if it does not exist we can simply set 
> OPENJDK=true (no need to do it in the distro file - as Coleen has 
> pointed out offline). Had OPENJDK been set to true initially we would 
> have looked for a different altsrc but it still would not exist so 
> we'd execute the same logic that would (redundantly) set OPENJDK to 
> true again.
>
> We will need to fix the top-level build regardless, so that it passes 
> down OPENJDK=true.

Yes, I will file a bug (actually if someone else can do that before me, 
that would be great because I don't know what subcategory to file it 
in).   And provide Mark's suggested fix in the bug.

>
> David (signing off for the night)

Thanks David.  It's almost tomorrow for you now.

Coleen
> -----
>
> On 4/10/2012 11:29 PM, David Holmes wrote:
>> On 4/10/2012 9:43 PM, Coleen Phillimore wrote:
>>> On 10/3/2012 7:01 PM, David Holmes wrote:
>>>> Coleen,
>>>>
>>>> On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>>>>>
>>>>> The logic for setting up OPENJDK is different but there was some
>>>>> code to
>>>>> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
>>>>> closed files. Anyway, I think this code is correct now. It sets 
>>>>> OPENJDK
>>>>> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux both 
>>>>> ways
>>>>> now.
>>>>
>>>> Sorry but that is the wrong fix. If anything OPENJDK should be
>>>> controlling which distro file gets included. The logic for that in
>>>> buildtree.make is:
>>>>
>>>> ifndef HOTSPOT_VM_DISTRO
>>>> ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
>>>> include $(GAMMADIR)/make/hotspot_distro
>>>> else
>>>> include $(GAMMADIR)/make/openjdk_distro
>>>> endif
>>>> endif
>>>>
>>>> So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true
>>>> setting - and that file is the wrong place to set that variable.
>>>
>>> Actually, if you set HOTSPOT_VM_DISTRO, that implies that you want some
>>> other distro regardless of whether the Oracle closed repositories 
>>> exist.
>>> So OPENJDK should be false in this case.
>>
>> HOTSPOT_VM_DISTRO just gives a name to the distro. It can still be
>> OpenJDK, or more to the point it will fail to build if not treated as
>> OPENJDK when built externally.
>>
>> Further the logic that chooses to include hotspot_distro or
>> openjdk_distro uses the altsrc macros, but they are in turn defined
>> depending on whether OPENJDK is true or not. So there seems to be a
>> circular dependency there.
>>
>>> i still think this change does exactly what we want. I tried the
>>> suggested change you had in defs.make and it was pretty horrible. This
>>> checks this same thing more cleanly.
>>
>> I've sent a more detailed suggestion offline. This whole situation is a
>> complete mess (and nothing directly to do with this specific bug fix).
>>
>> Thanks,
>> David
>> -----
>>
>>> Thanks,
>>> Coleen
>>>>
>>>> To remedy this in hotspot, for a hotspot-only build, we need to check
>>>> for something that indicates this is not an OPENJDK build. The
>>>> presence of the closed repos is generally what is used for that. But
>>>> placing such a check correctly is extremely awkward (something
>>>> compounded by the fact that present hotspot make/defs.make has a
>>>> couple of bugs in ordering that the minimal VM changes will fix). So
>>>> right now I can't tell you exactly how to fix this in a more suitable
>>>> way.
>>>>
>>>> David
>>>> -----
>>>>
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>>>>>
>>>>> I also filed a bug 8000408 for Oracle JVM to support this in the
>>>>> future.
>>>>>
>>>>> Please review, again, and thank you for your patience!
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>>>>>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>>>>>> To be clear, when hotspot is built as part of a full build then it
>>>>>>> should be being passed the OPENJDK variable. But I don't think 
>>>>>>> it is,
>>>>>>> which is a bug in the top-level make logic. It has been a harmless
>>>>>>> bug
>>>>>>> to-date
>>>>>> Yeah, it looks like it might have been the intention to pass it down
>>>>>> through COMMON_BUILD_ARGUMENTS?
>>>>>>
>>>>>>> To allow for the old build system, and for standalone builds within
>>>>>>> that
>>>>>>> system, I think the hotspot/make/defs.make would have to duplicate
>>>>>>> the
>>>>>>> logic that is in jdk/make/common/Defs.gmk.
>>>>>> I looked at that, but the build makefile setups are pretty 
>>>>>> different.
>>>>>> The simplest seems to be to at least add it to the
>>>>>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>>>>>
>>>>>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03 
>>>>>> 16:08:00.239767294
>>>>>> +0200
>>>>>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201 
>>>>>> +0200
>>>>>> @@ -325,6 +325,10 @@
>>>>>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>>>>>> STATIC_CXX=$(STATIC_CXX)
>>>>>>
>>>>>> +ifdef OPENJDK
>>>>>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>>>>>> +endif
>>>>>> +
>>>>>> ifdef ARCH_DATA_MODEL
>>>>>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>>>>>> endif
>>>>>>
>>>>>> That works for my setup and should cover most default builds of
>>>>>> openjdk
>>>>>> starting from the top-level. Does that look OK to you?
>>>>>>
>>>>>> Next we have to figure out how to get the default for OPENJDK set to
>>>>>> true in a plain hotspot dir. But the logic seems to be somewhat
>>>>>> different from what the jdk dir does. We might be able to use the
>>>>>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>>>>>> executed when the the hotspot build detects that it doesn't have
>>>>>> "closed" components. But I am not entirely sure how to satisfy the
>>>>>> restriction listed there:
>>>>>> # This file format must remain compatible with both
>>>>>> # GNU Makefile and Microsoft nmake formats.
>>>>>> Since I don't know anything about nmake.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Mark
>>>

From keith.mcguigan at oracle.com  Thu Oct  4 15:49:54 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Thu, 04 Oct 2012 18:49:54 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506DFFD9.8010902@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
Message-ID: <506E1292.20600@oracle.com>


Still good...

--
- Keith

On 10/4/2012 5:30 PM, Coleen Phillimore wrote:
>
> I have modified this change in two ways.  Rather than adding setting
> OPENJDK to openjdk_distro, I am setting it after openjdk_distro is
> included if OPENJDK isn't set, which I was the change that David and I
> discussed offline.  It is redundant but not circular and is safe if
> OPENJDK is passed down.    I will file a bug against the JDK build to do
> this in the future, but many of us build only the hotspot repository.
>
> The other change was that dtrace.hpp didn't build on windows.  The linux
> definitions expand to null for windows.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638_5
>
> A couple of comments below.
>
> On 10/4/2012 10:00 AM, David Holmes wrote:
>> For the record, the suggested fix to defs.make doesn't presently work
>> because defs.make isn't seen by all makefiles used by the various
>> sub-makes. But that will change with the changes coming as part of the
>> minimal VM work.
>
> Even if this test is included in defs.make and OPENJDK is set, the
> dtrace.make makefile won't get this definition.  It only gets flags in
> flags.make created by buildtree.make.  So I didn't see any reason to
> move this to defs.make.   I had a look at the latest minimal vm changes
> and this doesn't affect that.
>>
>> Coleen's fix seemed to have a circular dependency, but thinking more
>> it is only partially circular - if that makes sense :) The default
>> path for altsrc depends on whether OPENJDK is true or not, but the
>> actual existence check will still work. So if OPENJDK is not set we
>> will look for src/closed, and if that exists then we are not an
>> OPENJDK build - else if it does not exist we can simply set
>> OPENJDK=true (no need to do it in the distro file - as Coleen has
>> pointed out offline). Had OPENJDK been set to true initially we would
>> have looked for a different altsrc but it still would not exist so
>> we'd execute the same logic that would (redundantly) set OPENJDK to
>> true again.
>>
>> We will need to fix the top-level build regardless, so that it passes
>> down OPENJDK=true.
>
> Yes, I will file a bug (actually if someone else can do that before me,
> that would be great because I don't know what subcategory to file it
> in).   And provide Mark's suggested fix in the bug.
>
>>
>> David (signing off for the night)
>
> Thanks David.  It's almost tomorrow for you now.
>
> Coleen
>> -----
>>
>> On 4/10/2012 11:29 PM, David Holmes wrote:
>>> On 4/10/2012 9:43 PM, Coleen Phillimore wrote:
>>>> On 10/3/2012 7:01 PM, David Holmes wrote:
>>>>> Coleen,
>>>>>
>>>>> On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>> The logic for setting up OPENJDK is different but there was some
>>>>>> code to
>>>>>> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
>>>>>> closed files. Anyway, I think this code is correct now. It sets
>>>>>> OPENJDK
>>>>>> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux both
>>>>>> ways
>>>>>> now.
>>>>>
>>>>> Sorry but that is the wrong fix. If anything OPENJDK should be
>>>>> controlling which distro file gets included. The logic for that in
>>>>> buildtree.make is:
>>>>>
>>>>> ifndef HOTSPOT_VM_DISTRO
>>>>> ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
>>>>> include $(GAMMADIR)/make/hotspot_distro
>>>>> else
>>>>> include $(GAMMADIR)/make/openjdk_distro
>>>>> endif
>>>>> endif
>>>>>
>>>>> So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true
>>>>> setting - and that file is the wrong place to set that variable.
>>>>
>>>> Actually, if you set HOTSPOT_VM_DISTRO, that implies that you want some
>>>> other distro regardless of whether the Oracle closed repositories
>>>> exist.
>>>> So OPENJDK should be false in this case.
>>>
>>> HOTSPOT_VM_DISTRO just gives a name to the distro. It can still be
>>> OpenJDK, or more to the point it will fail to build if not treated as
>>> OPENJDK when built externally.
>>>
>>> Further the logic that chooses to include hotspot_distro or
>>> openjdk_distro uses the altsrc macros, but they are in turn defined
>>> depending on whether OPENJDK is true or not. So there seems to be a
>>> circular dependency there.
>>>
>>>> i still think this change does exactly what we want. I tried the
>>>> suggested change you had in defs.make and it was pretty horrible. This
>>>> checks this same thing more cleanly.
>>>
>>> I've sent a more detailed suggestion offline. This whole situation is a
>>> complete mess (and nothing directly to do with this specific bug fix).
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>> Thanks,
>>>> Coleen
>>>>>
>>>>> To remedy this in hotspot, for a hotspot-only build, we need to check
>>>>> for something that indicates this is not an OPENJDK build. The
>>>>> presence of the closed repos is generally what is used for that. But
>>>>> placing such a check correctly is extremely awkward (something
>>>>> compounded by the fact that present hotspot make/defs.make has a
>>>>> couple of bugs in ordering that the minimal VM changes will fix). So
>>>>> right now I can't tell you exactly how to fix this in a more suitable
>>>>> way.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>>>>>>
>>>>>> I also filed a bug 8000408 for Oracle JVM to support this in the
>>>>>> future.
>>>>>>
>>>>>> Please review, again, and thank you for your patience!
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>>>>>>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>>>>>>> To be clear, when hotspot is built as part of a full build then it
>>>>>>>> should be being passed the OPENJDK variable. But I don't think
>>>>>>>> it is,
>>>>>>>> which is a bug in the top-level make logic. It has been a harmless
>>>>>>>> bug
>>>>>>>> to-date
>>>>>>> Yeah, it looks like it might have been the intention to pass it down
>>>>>>> through COMMON_BUILD_ARGUMENTS?
>>>>>>>
>>>>>>>> To allow for the old build system, and for standalone builds within
>>>>>>>> that
>>>>>>>> system, I think the hotspot/make/defs.make would have to duplicate
>>>>>>>> the
>>>>>>>> logic that is in jdk/make/common/Defs.gmk.
>>>>>>> I looked at that, but the build makefile setups are pretty
>>>>>>> different.
>>>>>>> The simplest seems to be to at least add it to the
>>>>>>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>>>>>>
>>>>>>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03
>>>>>>> 16:08:00.239767294
>>>>>>> +0200
>>>>>>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201
>>>>>>> +0200
>>>>>>> @@ -325,6 +325,10 @@
>>>>>>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>>>>>>> STATIC_CXX=$(STATIC_CXX)
>>>>>>>
>>>>>>> +ifdef OPENJDK
>>>>>>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>>>>>>> +endif
>>>>>>> +
>>>>>>> ifdef ARCH_DATA_MODEL
>>>>>>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>>>>>>> endif
>>>>>>>
>>>>>>> That works for my setup and should cover most default builds of
>>>>>>> openjdk
>>>>>>> starting from the top-level. Does that look OK to you?
>>>>>>>
>>>>>>> Next we have to figure out how to get the default for OPENJDK set to
>>>>>>> true in a plain hotspot dir. But the logic seems to be somewhat
>>>>>>> different from what the jdk dir does. We might be able to use the
>>>>>>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>>>>>>> executed when the the hotspot build detects that it doesn't have
>>>>>>> "closed" components. But I am not entirely sure how to satisfy the
>>>>>>> restriction listed there:
>>>>>>> # This file format must remain compatible with both
>>>>>>> # GNU Makefile and Microsoft nmake formats.
>>>>>>> Since I don't know anything about nmake.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Mark
>>>>

From david.holmes at oracle.com  Thu Oct  4 16:19:48 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Oct 2012 09:19:48 +1000
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506DFFD9.8010902@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
Message-ID: <506E1994.8040305@oracle.com>

Thanks for your patience and perseverence on this Coleen.

On 5/10/2012 7:30 AM, Coleen Phillimore wrote:
> I have modified this change in two ways. Rather than adding setting
> OPENJDK to openjdk_distro, I am setting it after openjdk_distro is
> included if OPENJDK isn't set, which I was the change that David and I
> discussed offline. It is redundant but not circular and is safe if
> OPENJDK is passed down. I will file a bug against the JDK build to do
> this in the future, but many of us build only the hotspot repository.
>
> The other change was that dtrace.hpp didn't build on windows. The linux
> definitions expand to null for windows.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638_5

Looks okay to me.

> A couple of comments below.
>
> On 10/4/2012 10:00 AM, David Holmes wrote:
>> For the record, the suggested fix to defs.make doesn't presently work
>> because defs.make isn't seen by all makefiles used by the various
>> sub-makes. But that will change with the changes coming as part of the
>> minimal VM work.
>
> Even if this test is included in defs.make and OPENJDK is set, the
> dtrace.make makefile won't get this definition. It only gets flags in
> flags.make created by buildtree.make. So I didn't see any reason to move
> this to defs.make. I had a look at the latest minimal vm changes and
> this doesn't affect that.

Yeah there's still a piece missing. :(

>> We will need to fix the top-level build regardless, so that it passes
>> down OPENJDK=true.
>
> Yes, I will file a bug (actually if someone else can do that before me,
> that would be great because I don't know what subcategory to file it
> in). And provide Mark's suggested fix in the bug.

I will do that and push through the build repos.

Thanks,
David
-----

>
>>
>> David (signing off for the night)
>
> Thanks David. It's almost tomorrow for you now.
>
> Coleen
>> -----
>>
>> On 4/10/2012 11:29 PM, David Holmes wrote:
>>> On 4/10/2012 9:43 PM, Coleen Phillimore wrote:
>>>> On 10/3/2012 7:01 PM, David Holmes wrote:
>>>>> Coleen,
>>>>>
>>>>> On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>> The logic for setting up OPENJDK is different but there was some
>>>>>> code to
>>>>>> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
>>>>>> closed files. Anyway, I think this code is correct now. It sets
>>>>>> OPENJDK
>>>>>> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux both
>>>>>> ways
>>>>>> now.
>>>>>
>>>>> Sorry but that is the wrong fix. If anything OPENJDK should be
>>>>> controlling which distro file gets included. The logic for that in
>>>>> buildtree.make is:
>>>>>
>>>>> ifndef HOTSPOT_VM_DISTRO
>>>>> ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
>>>>> include $(GAMMADIR)/make/hotspot_distro
>>>>> else
>>>>> include $(GAMMADIR)/make/openjdk_distro
>>>>> endif
>>>>> endif
>>>>>
>>>>> So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true
>>>>> setting - and that file is the wrong place to set that variable.
>>>>
>>>> Actually, if you set HOTSPOT_VM_DISTRO, that implies that you want some
>>>> other distro regardless of whether the Oracle closed repositories
>>>> exist.
>>>> So OPENJDK should be false in this case.
>>>
>>> HOTSPOT_VM_DISTRO just gives a name to the distro. It can still be
>>> OpenJDK, or more to the point it will fail to build if not treated as
>>> OPENJDK when built externally.
>>>
>>> Further the logic that chooses to include hotspot_distro or
>>> openjdk_distro uses the altsrc macros, but they are in turn defined
>>> depending on whether OPENJDK is true or not. So there seems to be a
>>> circular dependency there.
>>>
>>>> i still think this change does exactly what we want. I tried the
>>>> suggested change you had in defs.make and it was pretty horrible. This
>>>> checks this same thing more cleanly.
>>>
>>> I've sent a more detailed suggestion offline. This whole situation is a
>>> complete mess (and nothing directly to do with this specific bug fix).
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>> Thanks,
>>>> Coleen
>>>>>
>>>>> To remedy this in hotspot, for a hotspot-only build, we need to check
>>>>> for something that indicates this is not an OPENJDK build. The
>>>>> presence of the closed repos is generally what is used for that. But
>>>>> placing such a check correctly is extremely awkward (something
>>>>> compounded by the fact that present hotspot make/defs.make has a
>>>>> couple of bugs in ordering that the minimal VM changes will fix). So
>>>>> right now I can't tell you exactly how to fix this in a more suitable
>>>>> way.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>>>>>>
>>>>>> I also filed a bug 8000408 for Oracle JVM to support this in the
>>>>>> future.
>>>>>>
>>>>>> Please review, again, and thank you for your patience!
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>>>>>>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>>>>>>> To be clear, when hotspot is built as part of a full build then it
>>>>>>>> should be being passed the OPENJDK variable. But I don't think
>>>>>>>> it is,
>>>>>>>> which is a bug in the top-level make logic. It has been a harmless
>>>>>>>> bug
>>>>>>>> to-date
>>>>>>> Yeah, it looks like it might have been the intention to pass it down
>>>>>>> through COMMON_BUILD_ARGUMENTS?
>>>>>>>
>>>>>>>> To allow for the old build system, and for standalone builds within
>>>>>>>> that
>>>>>>>> system, I think the hotspot/make/defs.make would have to duplicate
>>>>>>>> the
>>>>>>>> logic that is in jdk/make/common/Defs.gmk.
>>>>>>> I looked at that, but the build makefile setups are pretty
>>>>>>> different.
>>>>>>> The simplest seems to be to at least add it to the
>>>>>>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>>>>>>
>>>>>>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03
>>>>>>> 16:08:00.239767294
>>>>>>> +0200
>>>>>>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201
>>>>>>> +0200
>>>>>>> @@ -325,6 +325,10 @@
>>>>>>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>>>>>>> STATIC_CXX=$(STATIC_CXX)
>>>>>>>
>>>>>>> +ifdef OPENJDK
>>>>>>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>>>>>>> +endif
>>>>>>> +
>>>>>>> ifdef ARCH_DATA_MODEL
>>>>>>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>>>>>>> endif
>>>>>>>
>>>>>>> That works for my setup and should cover most default builds of
>>>>>>> openjdk
>>>>>>> starting from the top-level. Does that look OK to you?
>>>>>>>
>>>>>>> Next we have to figure out how to get the default for OPENJDK set to
>>>>>>> true in a plain hotspot dir. But the logic seems to be somewhat
>>>>>>> different from what the jdk dir does. We might be able to use the
>>>>>>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>>>>>>> executed when the the hotspot build detects that it doesn't have
>>>>>>> "closed" components. But I am not entirely sure how to satisfy the
>>>>>>> restriction listed there:
>>>>>>> # This file format must remain compatible with both
>>>>>>> # GNU Makefile and Microsoft nmake formats.
>>>>>>> Since I don't know anything about nmake.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Mark
>>>>

From serguei.spitsyn at oracle.com  Thu Oct  4 20:23:20 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 04 Oct 2012 20:23:20 -0700
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506DFFD9.8010902@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
Message-ID: <506E52A8.8020205@oracle.com>

Hi Coleen,

Looks good.

*src/share/vm/utilities/dtrace.hpp
*

  198 #define HS_DTRACE_PROBE9(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)\
  199   DTRACE_PROBE9(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)
  200 #define HS_DTRACE_PROBE10(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)\
  201   DTRACE_PROBE10(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)

   A question:
     Is it intentional that PROBE9 and PROBE10 have the same number of 
parameters?
     Should PROBE10 have extra parameter a9?


Thanks,
Serguei
*
*
On 10/4/12 2:30 PM, Coleen Phillimore wrote:
>
> I have modified this change in two ways.  Rather than adding setting 
> OPENJDK to openjdk_distro, I am setting it after openjdk_distro is 
> included if OPENJDK isn't set, which I was the change that David and I 
> discussed offline.  It is redundant but not circular and is safe if 
> OPENJDK is passed down.    I will file a bug against the JDK build to 
> do this in the future, but many of us build only the hotspot repository.
>
> The other change was that dtrace.hpp didn't build on windows.  The 
> linux definitions expand to null for windows.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638_5
>
> A couple of comments below.
>
> On 10/4/2012 10:00 AM, David Holmes wrote:
>> For the record, the suggested fix to defs.make doesn't presently work 
>> because defs.make isn't seen by all makefiles used by the various 
>> sub-makes. But that will change with the changes coming as part of 
>> the minimal VM work.
>
> Even if this test is included in defs.make and OPENJDK is set, the 
> dtrace.make makefile won't get this definition.  It only gets flags in 
> flags.make created by buildtree.make.  So I didn't see any reason to 
> move this to defs.make.   I had a look at the latest minimal vm 
> changes and this doesn't affect that.
>>
>> Coleen's fix seemed to have a circular dependency, but thinking more 
>> it is only partially circular - if that makes sense :) The default 
>> path for altsrc depends on whether OPENJDK is true or not, but the 
>> actual existence check will still work. So if OPENJDK is not set we 
>> will look for src/closed, and if that exists then we are not an 
>> OPENJDK build - else if it does not exist we can simply set 
>> OPENJDK=true (no need to do it in the distro file - as Coleen has 
>> pointed out offline). Had OPENJDK been set to true initially we would 
>> have looked for a different altsrc but it still would not exist so 
>> we'd execute the same logic that would (redundantly) set OPENJDK to 
>> true again.
>>
>> We will need to fix the top-level build regardless, so that it passes 
>> down OPENJDK=true.
>
> Yes, I will file a bug (actually if someone else can do that before 
> me, that would be great because I don't know what subcategory to file 
> it in).   And provide Mark's suggested fix in the bug.
>
>>
>> David (signing off for the night)
>
> Thanks David.  It's almost tomorrow for you now.
>
> Coleen
>> -----
>>
>> On 4/10/2012 11:29 PM, David Holmes wrote:
>>> On 4/10/2012 9:43 PM, Coleen Phillimore wrote:
>>>> On 10/3/2012 7:01 PM, David Holmes wrote:
>>>>> Coleen,
>>>>>
>>>>> On 4/10/2012 7:52 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>> The logic for setting up OPENJDK is different but there was some
>>>>>> code to
>>>>>> set up HOTSPOT_VM_DISTRO based on the presence or absence of certain
>>>>>> closed files. Anyway, I think this code is correct now. It sets 
>>>>>> OPENJDK
>>>>>> if HOTSPOT_VM_DISTRO is OpenJDK. I can build Hotspot on Linux 
>>>>>> both ways
>>>>>> now.
>>>>>
>>>>> Sorry but that is the wrong fix. If anything OPENJDK should be
>>>>> controlling which distro file gets included. The logic for that in
>>>>> buildtree.make is:
>>>>>
>>>>> ifndef HOTSPOT_VM_DISTRO
>>>>> ifeq ($(call if-has-altsrc,$(HS_COMMON_SRC)/,true,false),true)
>>>>> include $(GAMMADIR)/make/hotspot_distro
>>>>> else
>>>>> include $(GAMMADIR)/make/openjdk_distro
>>>>> endif
>>>>> endif
>>>>>
>>>>> So simply overriding HOTSPOT_VM_DISTRO would lose this OPENJDK=true
>>>>> setting - and that file is the wrong place to set that variable.
>>>>
>>>> Actually, if you set HOTSPOT_VM_DISTRO, that implies that you want 
>>>> some
>>>> other distro regardless of whether the Oracle closed repositories 
>>>> exist.
>>>> So OPENJDK should be false in this case.
>>>
>>> HOTSPOT_VM_DISTRO just gives a name to the distro. It can still be
>>> OpenJDK, or more to the point it will fail to build if not treated as
>>> OPENJDK when built externally.
>>>
>>> Further the logic that chooses to include hotspot_distro or
>>> openjdk_distro uses the altsrc macros, but they are in turn defined
>>> depending on whether OPENJDK is true or not. So there seems to be a
>>> circular dependency there.
>>>
>>>> i still think this change does exactly what we want. I tried the
>>>> suggested change you had in defs.make and it was pretty horrible. This
>>>> checks this same thing more cleanly.
>>>
>>> I've sent a more detailed suggestion offline. This whole situation is a
>>> complete mess (and nothing directly to do with this specific bug fix).
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>> Thanks,
>>>> Coleen
>>>>>
>>>>> To remedy this in hotspot, for a hotspot-only build, we need to check
>>>>> for something that indicates this is not an OPENJDK build. The
>>>>> presence of the closed repos is generally what is used for that. But
>>>>> placing such a check correctly is extremely awkward (something
>>>>> compounded by the fact that present hotspot make/defs.make has a
>>>>> couple of bugs in ordering that the minimal VM changes will fix). So
>>>>> right now I can't tell you exactly how to fix this in a more suitable
>>>>> way.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_4/
>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7170638
>>>>>>
>>>>>> I also filed a bug 8000408 for Oracle JVM to support this in the
>>>>>> future.
>>>>>>
>>>>>> Please review, again, and thank you for your patience!
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>> On 10/3/2012 10:38 AM, Mark Wielaard wrote:
>>>>>>> On Wed, 2012-10-03 at 23:00 +1000, David Holmes wrote:
>>>>>>>> To be clear, when hotspot is built as part of a full build then it
>>>>>>>> should be being passed the OPENJDK variable. But I don't think 
>>>>>>>> it is,
>>>>>>>> which is a bug in the top-level make logic. It has been a harmless
>>>>>>>> bug
>>>>>>>> to-date
>>>>>>> Yeah, it looks like it might have been the intention to pass it 
>>>>>>> down
>>>>>>> through COMMON_BUILD_ARGUMENTS?
>>>>>>>
>>>>>>>> To allow for the old build system, and for standalone builds 
>>>>>>>> within
>>>>>>>> that
>>>>>>>> system, I think the hotspot/make/defs.make would have to duplicate
>>>>>>>> the
>>>>>>>> logic that is in jdk/make/common/Defs.gmk.
>>>>>>> I looked at that, but the build makefile setups are pretty 
>>>>>>> different.
>>>>>>> The simplest seems to be to at least add it to the
>>>>>>> COMMON_BUILD_ARGUMENTS at the top-level like so:
>>>>>>>
>>>>>>> --- openjdk/make/Defs-internal.gmk.orig 2012-10-03 
>>>>>>> 16:08:00.239767294
>>>>>>> +0200
>>>>>>> +++ openjdk/make/Defs-internal.gmk 2012-10-03 16:07:50.508629201 
>>>>>>> +0200
>>>>>>> @@ -325,6 +325,10 @@
>>>>>>> PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) \
>>>>>>> STATIC_CXX=$(STATIC_CXX)
>>>>>>>
>>>>>>> +ifdef OPENJDK
>>>>>>> + COMMON_BUILD_ARGUMENTS += OPENJDK=$(OPENJDK)
>>>>>>> +endif
>>>>>>> +
>>>>>>> ifdef ARCH_DATA_MODEL
>>>>>>> COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)
>>>>>>> endif
>>>>>>>
>>>>>>> That works for my setup and should cover most default builds of
>>>>>>> openjdk
>>>>>>> starting from the top-level. Does that look OK to you?
>>>>>>>
>>>>>>> Next we have to figure out how to get the default for OPENJDK 
>>>>>>> set to
>>>>>>> true in a plain hotspot dir. But the logic seems to be somewhat
>>>>>>> different from what the jdk dir does. We might be able to use the
>>>>>>> openjdk/hostpot/make/openjdk_distro Makefile snippet. Since that is
>>>>>>> executed when the the hotspot build detects that it doesn't have
>>>>>>> "closed" components. But I am not entirely sure how to satisfy the
>>>>>>> restriction listed there:
>>>>>>> # This file format must remain compatible with both
>>>>>>> # GNU Makefile and Microsoft nmake formats.
>>>>>>> Since I don't know anything about nmake.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Mark
>>>>


From jon.masamitsu at oracle.com  Fri Oct  5 02:54:18 2012
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Fri, 05 Oct 2012 09:54:18 +0000
Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets
Message-ID: <20121005095605.DEDF4471C5@hg.openjdk.java.net>

Changeset: 988bf00cc564
Author:    johnc
Date:      2012-09-27 15:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/988bf00cc564

7200261: G1: Liveness counting inconsistencies during marking verification
Summary: The clipping code in the routine that sets the bits for a range of cards, in the liveness accounting verification code was incorrect. It set all the bits in the card bitmap from the given starting index which would lead to spurious marking verification failures.
Reviewed-by: brutisso, jwilhelm, jmasa

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp

Changeset: 5c8fbbfed964
Author:    stefank
Date:      2012-10-01 11:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5c8fbbfed964

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java

Changeset: 85f1cded9793
Author:    stefank
Date:      2012-09-28 15:34 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/85f1cded9793

8000230: Change os::print_location to be more descriptive when a location is pointing into an object
Reviewed-by: mgerdin, twisti

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

Changeset: 86af3dacab81
Author:    stefank
Date:      2012-10-01 13:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/86af3dacab81

8000227: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream
Reviewed-by: brutisso, sla, jmasa, coleenp

! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp

Changeset: 87ac5c0a404d
Author:    stefank
Date:      2012-10-01 13:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/87ac5c0a404d

8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location
Reviewed-by: brutisso, neliasso

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

Changeset: f81a7c0c618d
Author:    jmasa
Date:      2012-10-03 08:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f81a7c0c618d

7199349: NPG: PS: Crash seen in jprt
Reviewed-by: johnc

! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 22b8d3d181d9
Author:    jwilhelm
Date:      2012-10-03 20:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/22b8d3d181d9

8000351: Tenuring threshold should be unsigned
Summary: Change the flags and variables related to tenuring threshold to be unsigned
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/shared/ageTable.cpp
! src/share/vm/gc_implementation/shared/ageTable.hpp
! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp
! src/share/vm/memory/defNewGeneration.hpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp
! src/share/vm/oops/markOop.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp


From mjw at redhat.com  Fri Oct  5 04:23:03 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Fri, 05 Oct 2012 13:23:03 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506E52A8.8020205@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
	<506E52A8.8020205@oracle.com>
Message-ID: <1349436183.3478.17.camel@springer.wildebeest.org>

On Thu, 2012-10-04 at 20:23 -0700, serguei.spitsyn at oracle.com wrote:
> src/share/vm/utilities/dtrace.hpp
>  198 #define HS_DTRACE_PROBE9(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)\
>  199   DTRACE_PROBE9(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)
>  200 #define HS_DTRACE_PROBE10(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)\
>  201   DTRACE_PROBE10(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)
>   A question:
>     Is it intentional that PROBE9 and PROBE10 have the same number of
> parameters?
>     Should PROBE10 have extra parameter a9?

Good catch. Luckily there are no probes in hotspot with 10 arguments.
There is one probe with 9 arguments though, method__compile__end.
Yes, PROBE10 should have 10 arguments, not 9.

Thanks,

Mark

From mjw at redhat.com  Fri Oct  5 04:00:06 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Fri, 05 Oct 2012 13:00:06 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <506DFFD9.8010902@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
Message-ID: <1349434806.3478.10.camel@springer.wildebeest.org>

On Thu, 2012-10-04 at 17:30 -0400, Coleen Phillimore wrote:
> The other change was that dtrace.hpp didn't build on windows.  The linux 
> definitions expand to null for windows.

> -+#elif defined(LINUX)
> ++#else
>  +// Systemtap dtrace compatible probes on GNU/Linux don't.
> ++// If dtrace is disabled this macro becomes NULL
>  +#define HS_DTRACE_PROBE_DECL_N(provider,name,args)
>  +#define HS_DTRACE_PROBE_CDECL_N(provider,name,args)
> -+#else
> -+#error "USDT1 enabled for unknown os"
>  +#endif

I haven't had time to do a full rebuild here, but that change should be
fine. I am a little surprised the windows build picks up the definitions
from the USDT1/LINUX part. But empty defines should be fine. I don't
have Windows around though, so cannot test myself.

> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/

Also thanks for picking up the buildtree.make changes for bsd and
solaris. Note that this version doesn't include the new testcase, don't
know if that was intentional?

Cheers,

Mark

From joseph.provino at oracle.com  Fri Oct  5 07:59:48 2012
From: joseph.provino at oracle.com (Joe Provino)
Date: Fri, 05 Oct 2012 10:59:48 -0400
Subject: Request for Review: Conditionalize source so that functionality can
	be easily included or excluded
Message-ID: <506EF5E4.7070107@oracle.com>

The latest and hopefully final webrev is here:

http://cr.openjdk.java.net/~jprovino/7189254/webrev.10 
<http://cr.openjdk.java.net/%7Ejprovino/7189254/webrev.10/>

The changes are to make/{linux,bsd}/gcc.make to ensure that
CFLAGS and OPT_CFLAGS behave the way they did before any changes.

joe


From john.coomes at oracle.com  Fri Oct  5 11:26:44 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Oct 2012 18:26:44 +0000
Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets
Message-ID: <20121005182652.28904471D2@hg.openjdk.java.net>

Changeset: 2e6857353b2c
Author:    johnc
Date:      2012-10-04 10:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2e6857353b2c

8000311: G1: ParallelGCThreads==0 broken
Summary: Divide by zero error, if ParallelGCThreads is 0, when adjusting the PLAB size.
Reviewed-by: jmasa, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp

Changeset: 097d78aaf2b5
Author:    jmasa
Date:      2012-10-04 10:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/097d78aaf2b5

7198873: NPG: VM Does not unload classes with UseConcMarkSweepGC
Reviewed-by: johnc, mgerdin, jwilhelm

! src/share/vm/gc_implementation/shared/vmGCOperations.cpp

Changeset: ca70b919819f
Author:    jmasa
Date:      2012-10-04 14:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca70b919819f

Merge



From vladimir.kozlov at oracle.com  Fri Oct  5 13:10:40 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Fri, 05 Oct 2012 20:10:40 +0000
Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets
Message-ID: <20121005201052.116A5471D6@hg.openjdk.java.net>

Changeset: f6b0eb4e44cf
Author:    twisti
Date:      2012-10-01 14:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f6b0eb4e44cf

7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path
Reviewed-by: jrose, kvn

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciClassList.hpp
+ src/share/vm/ci/ciMethodType.hpp
! src/share/vm/ci/ciObject.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciSignature.cpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/ci/ciStreams.cpp
! src/share/vm/ci/ciStreams.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp

Changeset: 859c45fb8cea
Author:    kvn
Date:      2012-10-02 12:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/859c45fb8cea

7201026: add vector for shift count
Summary: Add generation of vectors for scalar shift count.
Reviewed-by: roland, twisti, dlong

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
! test/compiler/7200264/Test7200264.sh

Changeset: f13867c41f73
Author:    kvn
Date:      2012-10-02 14:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f13867c41f73

7199742: A lot of C2 OSR compilations of the same method's bci
Summary: Don't clone head of OSR loop.
Reviewed-by: jrose, twisti

! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/opto/parse1.cpp
+ test/compiler/7199742/Test7199742.java

Changeset: bf2edd3c9b0f
Author:    neliasso
Date:      2012-10-04 06:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf2edd3c9b0f

8000102: Resolve include conflicts
Summary: Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files.
Reviewed-by: kvn
Contributed-by: nils.eliasson at oracle.com

! 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/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.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

Changeset: 685457683e86
Author:    kvn
Date:      2012-10-05 10:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/685457683e86

Merge



From vladimir.x.ivanov at oracle.com  Fri Oct  5 13:33:47 2012
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 06 Oct 2012 00:33:47 +0400
Subject: RFR (XS): 8000485: Hotspot build fails in Solaris Studio IDE when
	building dtrace
Message-ID: <506F442B.2030508@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8000485/webrev.00
6 lines changed: 0 ins; 0 del; 6 mod

Solaris Studio has discovery functionality, which allows to 
automatically extract information about a project by instrumenting it's 
build process. When trying to build HotSpot from Solaris Studio on 
Solaris, the build fails: tracing library can't be found when generating 
JVM offsets for DTrace-related part, since LD_LIBRARY_PATH is overridden 
and libBuildTrace.so isn't on the path anymore.

The fix is to prepend '.' to the existing native library path, instead 
of overriding it with current folder location.

Also, fixed similar problem on MacOSX.

Testing: JPRT, remote build using Solaris Studio IDE.

Best regards,
Vladimir Ivanov

[1] https://jbs.oracle.com/bugs/browse/JDK-8000485

From vladimir.kozlov at oracle.com  Fri Oct  5 14:36:49 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 05 Oct 2012 14:36:49 -0700
Subject: RFR (XS): 8000485: Hotspot build fails in Solaris Studio IDE
	when building dtrace
In-Reply-To: <506F442B.2030508@oracle.com>
References: <506F442B.2030508@oracle.com>
Message-ID: <506F52F1.1000803@oracle.com>

Looks good.

Thanks,
Vladimir

Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8000485/webrev.00
> 6 lines changed: 0 ins; 0 del; 6 mod
> 
> Solaris Studio has discovery functionality, which allows to 
> automatically extract information about a project by instrumenting it's 
> build process. When trying to build HotSpot from Solaris Studio on 
> Solaris, the build fails: tracing library can't be found when generating 
> JVM offsets for DTrace-related part, since LD_LIBRARY_PATH is overridden 
> and libBuildTrace.so isn't on the path anymore.
> 
> The fix is to prepend '.' to the existing native library path, instead 
> of overriding it with current folder location.
> 
> Also, fixed similar problem on MacOSX.
> 
> Testing: JPRT, remote build using Solaris Studio IDE.
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] https://jbs.oracle.com/bugs/browse/JDK-8000485

From vladimir.kozlov at oracle.com  Fri Oct  5 15:03:26 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 05 Oct 2012 15:03:26 -0700
Subject: CFV: New HSX Committer: Nils Eliasson
Message-ID: <506F592E.1060602@oracle.com>

I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX Committer.

Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot 
development, he worked on JRockit VM in Oracle. He contributed 8 changesets to 
HSX project and he is qualified to be committer [1]:

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41

Votes are due by Oct 19, 2012.

Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Thanks,
Vladimir Kozlov

[1] http://openjdk.java.net/projects/#project-committer
[2] http://openjdk.java.net/census#hsx
[3] http://openjdk.java.net/projects#committer-vote


From serguei.spitsyn at oracle.com  Fri Oct  5 15:07:57 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 05 Oct 2012 15:07:57 -0700
Subject: RFR (XS): 8000485: Hotspot build fails in Solaris Studio IDE
	when building dtrace
In-Reply-To: <506F442B.2030508@oracle.com>
References: <506F442B.2030508@oracle.com>
Message-ID: <506F5A3D.7090108@oracle.com>

Looks good.

Thank you for fixing it!
Serguei

On 10/5/12 1:33 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8000485/webrev.00
> 6 lines changed: 0 ins; 0 del; 6 mod
>
> Solaris Studio has discovery functionality, which allows to 
> automatically extract information about a project by instrumenting 
> it's build process. When trying to build HotSpot from Solaris Studio 
> on Solaris, the build fails: tracing library can't be found when 
> generating JVM offsets for DTrace-related part, since LD_LIBRARY_PATH 
> is overridden and libBuildTrace.so isn't on the path anymore.
>
> The fix is to prepend '.' to the existing native library path, instead 
> of overriding it with current folder location.
>
> Also, fixed similar problem on MacOSX.
>
> Testing: JPRT, remote build using Solaris Studio IDE.
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://jbs.oracle.com/bugs/browse/JDK-8000485


From daniel.daugherty at oracle.com  Fri Oct  5 15:09:03 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 05 Oct 2012 16:09:03 -0600
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <506F5A7F.10309@oracle.com>

Vote: yes

Dan


On 10/5/12 4:03 PM, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX 
> Committer.
>
> Nils is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot development, he worked on JRockit VM in Oracle. He contributed 
> 8 changesets to HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
>
> Votes are due by Oct 19, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From vladimir.x.ivanov at oracle.com  Fri Oct  5 15:14:02 2012
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 06 Oct 2012 02:14:02 +0400
Subject: RFR (XS): 8000485: Hotspot build fails in Solaris Studio IDE
	when building dtrace
In-Reply-To: <506F5A3D.7090108@oracle.com>
References: <506F442B.2030508@oracle.com> <506F5A3D.7090108@oracle.com>
Message-ID: <506F5BAA.90208@oracle.com>

Vladimir, Serguei, thank you for review.

Best regards,
Vladimir Ivanov

On 10/6/12 2:07 AM, serguei.spitsyn at oracle.com wrote:
> Looks good.
>
> Thank you for fixing it!
> Serguei
>
> On 10/5/12 1:33 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8000485/webrev.00
>> 6 lines changed: 0 ins; 0 del; 6 mod
>>
>> Solaris Studio has discovery functionality, which allows to
>> automatically extract information about a project by instrumenting
>> it's build process. When trying to build HotSpot from Solaris Studio
>> on Solaris, the build fails: tracing library can't be found when
>> generating JVM offsets for DTrace-related part, since LD_LIBRARY_PATH
>> is overridden and libBuildTrace.so isn't on the path anymore.
>>
>> The fix is to prepend '.' to the existing native library path, instead
>> of overriding it with current folder location.
>>
>> Also, fixed similar problem on MacOSX.
>>
>> Testing: JPRT, remote build using Solaris Studio IDE.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://jbs.oracle.com/bugs/browse/JDK-8000485
>

From alejandro.murillo at oracle.com  Fri Oct  5 15:34:09 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 05 Oct 2012 22:34:09 +0000
Subject: hg: hsx/hsx25/hotspot: 21 new changesets
Message-ID: <20121005223517.F2CAE471D8@hg.openjdk.java.net>

Changeset: 2dd08e86a2bf
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2dd08e86a2bf

Added tag jdk8-b58 for changeset 6bb378c50828

! .hgtags

Changeset: 8a1a6b9b4f20
Author:    katleman
Date:      2012-10-03 15:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8a1a6b9b4f20

Merge

! .hgtags
- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java

Changeset: a3fd4914ac81
Author:    katleman
Date:      2012-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a3fd4914ac81

Added tag jdk8-b59 for changeset 8a1a6b9b4f20

! .hgtags

Changeset: 1b582b1bf7cb
Author:    amurillo
Date:      2012-09-28 14:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b582b1bf7cb

8000251: new hotspot build - hs25-b04
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 988bf00cc564
Author:    johnc
Date:      2012-09-27 15:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/988bf00cc564

7200261: G1: Liveness counting inconsistencies during marking verification
Summary: The clipping code in the routine that sets the bits for a range of cards, in the liveness accounting verification code was incorrect. It set all the bits in the card bitmap from the given starting index which would lead to spurious marking verification failures.
Reviewed-by: brutisso, jwilhelm, jmasa

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp

Changeset: 5c8fbbfed964
Author:    stefank
Date:      2012-10-01 11:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5c8fbbfed964

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java

Changeset: 85f1cded9793
Author:    stefank
Date:      2012-09-28 15:34 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/85f1cded9793

8000230: Change os::print_location to be more descriptive when a location is pointing into an object
Reviewed-by: mgerdin, twisti

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

Changeset: 86af3dacab81
Author:    stefank
Date:      2012-10-01 13:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/86af3dacab81

8000227: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream
Reviewed-by: brutisso, sla, jmasa, coleenp

! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp

Changeset: 87ac5c0a404d
Author:    stefank
Date:      2012-10-01 13:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/87ac5c0a404d

8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location
Reviewed-by: brutisso, neliasso

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

Changeset: f81a7c0c618d
Author:    jmasa
Date:      2012-10-03 08:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f81a7c0c618d

7199349: NPG: PS: Crash seen in jprt
Reviewed-by: johnc

! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 22b8d3d181d9
Author:    jwilhelm
Date:      2012-10-03 20:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/22b8d3d181d9

8000351: Tenuring threshold should be unsigned
Summary: Change the flags and variables related to tenuring threshold to be unsigned
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/shared/ageTable.cpp
! src/share/vm/gc_implementation/shared/ageTable.hpp
! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp
! src/share/vm/memory/defNewGeneration.hpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp
! src/share/vm/oops/markOop.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 2e6857353b2c
Author:    johnc
Date:      2012-10-04 10:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2e6857353b2c

8000311: G1: ParallelGCThreads==0 broken
Summary: Divide by zero error, if ParallelGCThreads is 0, when adjusting the PLAB size.
Reviewed-by: jmasa, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp

Changeset: 097d78aaf2b5
Author:    jmasa
Date:      2012-10-04 10:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/097d78aaf2b5

7198873: NPG: VM Does not unload classes with UseConcMarkSweepGC
Reviewed-by: johnc, mgerdin, jwilhelm

! src/share/vm/gc_implementation/shared/vmGCOperations.cpp

Changeset: ca70b919819f
Author:    jmasa
Date:      2012-10-04 14:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca70b919819f

Merge


Changeset: f6b0eb4e44cf
Author:    twisti
Date:      2012-10-01 14:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f6b0eb4e44cf

7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path
Reviewed-by: jrose, kvn

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciClassList.hpp
+ src/share/vm/ci/ciMethodType.hpp
! src/share/vm/ci/ciObject.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciSignature.cpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/ci/ciStreams.cpp
! src/share/vm/ci/ciStreams.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp

Changeset: 859c45fb8cea
Author:    kvn
Date:      2012-10-02 12:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/859c45fb8cea

7201026: add vector for shift count
Summary: Add generation of vectors for scalar shift count.
Reviewed-by: roland, twisti, dlong

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
! test/compiler/7200264/Test7200264.sh

Changeset: f13867c41f73
Author:    kvn
Date:      2012-10-02 14:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f13867c41f73

7199742: A lot of C2 OSR compilations of the same method's bci
Summary: Don't clone head of OSR loop.
Reviewed-by: jrose, twisti

! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/opto/parse1.cpp
+ test/compiler/7199742/Test7199742.java

Changeset: bf2edd3c9b0f
Author:    neliasso
Date:      2012-10-04 06:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf2edd3c9b0f

8000102: Resolve include conflicts
Summary: Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files.
Reviewed-by: kvn
Contributed-by: nils.eliasson at oracle.com

! 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/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.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

Changeset: 685457683e86
Author:    kvn
Date:      2012-10-05 10:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/685457683e86

Merge


Changeset: 1cc7a2a11d00
Author:    amurillo
Date:      2012-10-05 13:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1cc7a2a11d00

Merge


Changeset: 3cfd05b2219a
Author:    amurillo
Date:      2012-10-05 13:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3cfd05b2219a

Added tag hs25-b04 for changeset 1cc7a2a11d00

! .hgtags


From alejandro.murillo at oracle.com  Fri Oct  5 15:39:34 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 05 Oct 2012 16:39:34 -0600
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <506F61A6.5070706@oracle.com>

Vote: yes

Alejandro

On 10/5/2012 4:03 PM, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX 
> Committer.
>
> Nils is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot development, he worked on JRockit VM in Oracle. He contributed 
> 8 changesets to HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
>
> Votes are due by Oct 19, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From jesper.wilhelmsson at oracle.com  Fri Oct  5 15:45:01 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Sat, 6 Oct 2012 00:45:01 +0200
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <990BF2F4-2521-47B3-BC5C-119F159A7AB3@oracle.com>

Vote: yes

/Jesper

6 okt 2012 kl. 00:03 skrev Vladimir Kozlov <vladimir.kozlov at oracle.com>:

> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX Committer.
> 
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot development, he worked on JRockit VM in Oracle. He contributed 8 changesets to HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
> 
> Votes are due by Oct 19, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 

From david.holmes at oracle.com  Fri Oct  5 15:54:06 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 06 Oct 2012 08:54:06 +1000
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <506F650E.8090007@oracle.com>

Vote: yes

David

On 6/10/2012 8:03 AM, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX
> Committer.
>
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot
> development, he worked on JRockit VM in Oracle. He contributed 8
> changesets to HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
>
> Votes are due by Oct 19, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.
> Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From vladimir.kozlov at oracle.com  Fri Oct  5 15:58:42 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 05 Oct 2012 15:58:42 -0700
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <506F6622.1060305@oracle.com>

Vote: yes

Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX 
> Committer.
> 
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot 
> development, he worked on JRockit VM in Oracle. He contributed 8 
> changesets to HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
> 
> Votes are due by Oct 19, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 

From christian.thalinger at oracle.com  Fri Oct  5 16:15:05 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 5 Oct 2012 16:15:05 -0700
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <E3CEF7EF-C2F1-408E-9F87-0C1CA853AC4B@oracle.com>

Vote: yes

On Oct 5, 2012, at 3:03 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX Committer.
> 
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot development, he worked on JRockit VM in Oracle. He contributed 8 changesets to HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
> 
> Votes are due by Oct 19, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From john.r.rose at oracle.com  Fri Oct  5 16:40:03 2012
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 5 Oct 2012 16:40:03 -0700
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <07B8AB3C-9ECD-408E-8655-6FF5A2AE2F40@oracle.com>

Vote: yes

From alejandro.murillo at oracle.com  Fri Oct  5 16:43:59 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 05 Oct 2012 23:43:59 +0000
Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets
Message-ID: <20121005234414.A6907471DA@hg.openjdk.java.net>

Changeset: 2dd08e86a2bf
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2dd08e86a2bf

Added tag jdk8-b58 for changeset 6bb378c50828

! .hgtags

Changeset: 8a1a6b9b4f20
Author:    katleman
Date:      2012-10-03 15:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8a1a6b9b4f20

Merge

! .hgtags
- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java

Changeset: a3fd4914ac81
Author:    katleman
Date:      2012-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a3fd4914ac81

Added tag jdk8-b59 for changeset 8a1a6b9b4f20

! .hgtags

Changeset: 1cc7a2a11d00
Author:    amurillo
Date:      2012-10-05 13:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1cc7a2a11d00

Merge


Changeset: 3cfd05b2219a
Author:    amurillo
Date:      2012-10-05 13:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3cfd05b2219a

Added tag hs25-b04 for changeset 1cc7a2a11d00

! .hgtags

Changeset: 81e878c53615
Author:    amurillo
Date:      2012-10-05 13:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/81e878c53615

8000498: new hotspot build - hs25-b05
Reviewed-by: jcoomes

! make/hotspot_version


From zhengyu.gu at oracle.com  Fri Oct  5 17:41:39 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 05 Oct 2012 20:41:39 -0400
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <506F7E43.3080306@oracle.com>

Vote: yes

-Zhengyu

On 10/5/2012 6:03 PM, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX 
> Committer.
>
> Nils is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot development, he worked on JRockit VM in Oracle. He contributed 
> 8 changesets to HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
>
> Votes are due by Oct 19, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From bengt.rutisson at oracle.com  Sun Oct  7 12:14:53 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Sun, 07 Oct 2012 21:14:53 +0200
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <5071D4AD.20404@oracle.com>


Vote: yes

Bengt

On 2012-10-06 00:03, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX 
> Committer.
>
> Nils is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot development, he worked on JRockit VM in Oracle. He contributed 
> 8 changesets to HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
>
> Votes are due by Oct 19, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>


From david.holmes at oracle.com  Sun Oct  7 18:58:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Oct 2012 11:58:49 +1000
Subject: Request for Review: Conditionalize source so that functionality
	can be easily included or excluded
In-Reply-To: <506EF5E4.7070107@oracle.com>
References: <506EF5E4.7070107@oracle.com>
Message-ID: <50723359.1060205@oracle.com>

Thanks Joe, this looks good to go now.

David

On 6/10/2012 12:59 AM, Joe Provino wrote:
> The latest and hopefully final webrev is here:
>
> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10
> <http://cr.openjdk.java.net/%7Ejprovino/7189254/webrev.10/>
>
> The changes are to make/{linux,bsd}/gcc.make to ensure that
> CFLAGS and OPT_CFLAGS behave the way they did before any changes.
>
> joe
>

From christian.tornqvist at oracle.com  Mon Oct  8 00:40:45 2012
From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=)
Date: Mon, 8 Oct 2012 00:40:45 -0700 (PDT)
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <ee4bad43-f908-47c5-b5fb-9e7a3883c82a@default>

Vote: yes

-----Original Message-----
From: Vladimir Kozlov 
Sent: den 6 oktober 2012 00:03
To: hotspot-dev
Subject: CFV: New HSX Committer: Nils Eliasson

I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX Committer.

Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot development, he worked on JRockit VM in Oracle. He contributed 8 changesets to HSX project and he is qualified to be committer [1]:

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41

Votes are due by Oct 19, 2012.

Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Thanks,
Vladimir Kozlov

[1] http://openjdk.java.net/projects/#project-committer
[2] http://openjdk.java.net/census#hsx
[3] http://openjdk.java.net/projects#committer-vote


From roland.westrelin at oracle.com  Mon Oct  8 00:56:48 2012
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 8 Oct 2012 09:56:48 +0200
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <53CE36CE-305E-42ED-B542-C2E4ED0AE7BD@oracle.com>

Vote: yes

Roland.

From staffan.larsen at oracle.com  Mon Oct  8 00:58:48 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 8 Oct 2012 09:58:48 +0200
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <A454F8CE-F080-4C4C-8CE1-F2C766653C7A@oracle.com>

Vote: yes

On 6 okt 2012, at 00:03, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX Committer.
> 
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot development, he worked on JRockit VM in Oracle. He contributed 8 changesets to HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
> 
> Votes are due by Oct 19, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From frederic.parain at oracle.com  Mon Oct  8 01:36:31 2012
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 08 Oct 2012 10:36:31 +0200
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <5072908F.7090100@oracle.com>

Vote: yes

Fred

On 10/ 6/12 12:03 AM, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX
> Committer.
>
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot
> development, he worked on JRockit VM in Oracle. He contributed 8
> changesets to HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
>
> Votes are due by Oct 19, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at Oracle.com


From kevin.walls at oracle.com  Mon Oct  8 03:01:27 2012
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 08 Oct 2012 11:01:27 +0100
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <5072A477.6050505@oracle.com>

Vote: yes

On 05/10/12 23:03, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX 
> Committer.
>


From andreas.eriksson at oracle.com  Mon Oct  8 03:23:00 2012
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Mon, 08 Oct 2012 12:23:00 +0200
Subject: Fwd: Re: Review request (S): 7176220: 'Full GC' events miss date
	stamp information occasionally
In-Reply-To: <506DC747.10300@oracle.com>
References: <506AE1D3.1050103@oracle.com> <506D733D.10302@oracle.com>
	<506DC747.10300@oracle.com>
Message-ID: <5072A984.2050606@oracle.com>

Hi John,

If that TraceTime is changed to use PrintGC, then the logging becomes 
interleaved:

2012-10-08T12:16:42.121+0200: 0.171: [GC2012-10-08T12:16:42.121+0200: 
0.171: [GC 2667K->1043K(9920K), 0.0040520 secs]
, 0.0043620 secs]2012-10-08T12:16:42.127+0200: 0.177: 
[GC2012-10-08T12:16:42.128+0200: 0.177: [GC 3488K->1835K(9920K), 
0.0234120 secs]

That is probably the reason why it uses PrintGCDetails instead.

Thanks,
Andreas

On 10/04/2012 07:28 PM, John Cuthbertson wrote:
> Hi Andreas,
>
> This looks good to me except I have one question/comment:
>
> In genCollectedHeap.cpp, the old code was:
>
> 386     bool complete = full && (max_level == (n_gens()-1));
> 387     const char* gc_cause_prefix = complete ? "Full GC" : "GC";
> 388     gclog_or_tty->date_stamp(PrintGC && PrintGCDateStamps);
> 389     TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty);
> 390     TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), 
> PrintGCDetails, false, gclog_or_tty);
>
> The new code is:
>
> 386     bool complete = full && (max_level == (n_gens()-1));
> 387     const char* gc_cause_prefix = complete ? "Full GC" : "GC";
> 388     TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty);
> 389     TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), 
> PrintGCDetails, false, gclog_or_tty);
>
>
> In the old code, the date stamp was printed if PrintGC was enabled, 
> but the TraceTime::_doit field is set based upon the value of 
> PrintGCDetails. Looking at the other instantiations of the TraceTime 
> class, this seems inconsistent. I believe that the second parameter to 
> the TraceTime constructor should be PrintGC instead of PrintGCDetails.
>
> Regards,
>
> JohnC
>
> On 10/04/12 04:30, Andreas Eriksson wrote:
>> Hi,
>>
>> Can I have some reviews for the following change please:
>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ebrutisso/7176220/webrev.00/>
>>
>> See forwarded mails for more info.
>>
>> Regards,
>> Andreas
>>
>>
>> -------- Original Message --------
>> Subject:     Re: Review request (S): 7176220: 'Full GC' events miss 
>> date stamp information occasionally
>> Date:     Tue, 02 Oct 2012 14:45:07 +0200
>> From:     Bengt Rutisson <bengt.rutisson at oracle.com>
>> To:     Andreas Eriksson <andreas.eriksson at oracle.com>
>> CC:     hotspot-gc-dev at openjdk.java.net
>>
>>
>>
>>
>>
>> Hi Andreas,
>>
>> I think this looks good. I like that we treat PrintGCDateStamps and 
>> PrintGCTimeStamps in a consistent way.
>>
>> One thing that kind of worries me is that the TraceTime class is used 
>> from other parts of the JVM than just the GC. This means that you now 
>> get date stamps on compiler events if you enable PrintGCDateStamps. I 
>> think this is probably fine since they already get time stamps if you 
>> enable PrintGCTimeStamps. See for example how PhaseTraceTime is used 
>> in C1.
>>
>> Maybe we should send this review out on hotspot-dev to make sure that 
>> all teams have a chance to comment on this?
>>
>> Thanks,
>> Bengt
>>
>> On 2012-09-28 12:01, Andreas Eriksson wrote:
>>> Hi,
>>>
>>> Can I have some reviews for the following change please:
>>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Ebrutisso/7176220/webrev.00/>
>>>
>>> This fixes GC logs from genCollectedHeap.cpp where sometimes it 
>>> would not print date-stamps.
>>> The fix moves printing of date-stamps into TraceTime, where 
>>> time-stamps are already printed from.
>>>
>>> Bug with flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -verbose:gc 
>>> -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps:
>>> 2012-09-28T11:41:38.687+0200: 0.205: [Full GC 8702K->1012K(9920K), 
>>> 0.0108630 secs]
>>> 1.253: [Full GC 3326K->1012K(9920K), 0.0105750 secs]
>>> 2.299: [Full GC 7932K->1012K(9920K), 0.0100470 secs]
>>> 2012-09-28T11:41:41.813+0200: 3.331: [Full GC 8702K->1012K(9920K), 
>>> 0.0103210 secs]
>>>
>>> Another route that was investigated was to add the date-stamp call 
>>> directly in genCollectedHeap.cpp, but because of complex 
>>> interactions when a full GC was initiated from a non-full GC this 
>>> path was not taken.
>>>
>>>
>>> This will slightly change the logging output when using 
>>> -XX:+PrintGCDetails.
>>> Now date-stamps will also be printed inside other lines, as 
>>> time-stamps already are:
>>>
>>> Before:
>>> 2012-09-28T11:29:16.815+0200: 0.177: [GC0.177: [ParNew: 
>>> 2710K->46K(3072K), 0.0053590 secs] 3480K->1835K(9920K), 0.0055500 
>>> secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
>>>
>>> After:
>>> 2012-09-28T11:29:33.260+0200: 0.184: 
>>> [GC2012-09-28T11:29:33.261+0200: 0.184: [ParNew: 2642K->45K(3072K), 
>>> 0.0095770 secs] 3412K->1828K(9920K), 0.0097520 secs] [Times: 
>>> user=0.01 sys=0.00, real=0.01 secs]
>>>
>>> Thanks to Bengt Rutisson for helping with the change and webrev.
>>>
>>> Regards,
>>> Andreas
>>
>>
>>
>>
>


From coleen.phillimore at oracle.com  Mon Oct  8 07:38:08 2012
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Mon, 08 Oct 2012 10:38:08 -0400
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <5072E550.3070502@oracle.com>

Vote: yes

On 10/5/2012 6:03 PM, Vladimir Kozlov wrote:
> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX 
> Committer.
>
> Nils is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot development, he worked on JRockit VM in Oracle. He contributed 
> 8 changesets to HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
>
> Votes are due by Oct 19, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From karen.kinnear at oracle.com  Mon Oct  8 08:01:48 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 8 Oct 2012 11:01:48 -0400
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <879FE87F-2513-4C2E-B044-677A8947B7BA@oracle.com>

Vote: yes

Karen

On Oct 5, 2012, at 6:03 PM, Vladimir Kozlov wrote:

> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX Committer.
> 
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot development, he worked on JRockit VM in Oracle. He contributed 8 changesets to HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
> 
> Votes are due by Oct 19, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From coleen.phillimore at oracle.com  Mon Oct  8 09:17:50 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Oct 2012 12:17:50 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349436183.3478.17.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
	<506E52A8.8020205@oracle.com>
	<1349436183.3478.17.camel@springer.wildebeest.org>
Message-ID: <5072FCAE.8040403@oracle.com>


Thanks, that was a good find Serguei.  Thank you for finding it.  I've 
made this fix.
Coleen

On 10/5/2012 7:23 AM, Mark Wielaard wrote:
> On Thu, 2012-10-04 at 20:23 -0700, serguei.spitsyn at oracle.com wrote:
>> src/share/vm/utilities/dtrace.hpp
>>   198 #define HS_DTRACE_PROBE9(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)\
>>   199   DTRACE_PROBE9(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)
>>   200 #define HS_DTRACE_PROBE10(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)\
>>   201   DTRACE_PROBE10(provider,name,a0,a1,a2,a3,a4,a5,a6,a7,a8)
>>    A question:
>>      Is it intentional that PROBE9 and PROBE10 have the same number of
>> parameters?
>>      Should PROBE10 have extra parameter a9?
> Good catch. Luckily there are no probes in hotspot with 10 arguments.
> There is one probe with 9 arguments though, method__compile__end.
> Yes, PROBE10 should have 10 arguments, not 9.
>
> Thanks,
>
> Mark

From coleen.phillimore at oracle.com  Mon Oct  8 14:50:32 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Oct 2012 17:50:32 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349434806.3478.10.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
	<1349434806.3478.10.camel@springer.wildebeest.org>
Message-ID: <50734AA8.6060401@oracle.com>

Thank you for the further review.   A couple comments inline.

On 10/5/2012 7:00 AM, Mark Wielaard wrote:
> On Thu, 2012-10-04 at 17:30 -0400, Coleen Phillimore wrote:
>> The other change was that dtrace.hpp didn't build on windows.  The linux
>> definitions expand to null for windows.
>> -+#elif defined(LINUX)
>> ++#else
>>   +// Systemtap dtrace compatible probes on GNU/Linux don't.
>> ++// If dtrace is disabled this macro becomes NULL
>>   +#define HS_DTRACE_PROBE_DECL_N(provider,name,args)
>>   +#define HS_DTRACE_PROBE_CDECL_N(provider,name,args)
>> -+#else
>> -+#error "USDT1 enabled for unknown os"
>>   +#endif
> I haven't had time to do a full rebuild here, but that change should be
> fine. I am a little surprised the windows build picks up the definitions
> from the USDT1/LINUX part. But empty defines should be fine. I don't
> have Windows around though, so cannot test myself.

I wasn't completely thrilled with this but the Hotspot source uses the 
USDT1 macros if USDT2 isn't defined and that's what windows was 
compiling, so windows shared the definitions of USDT1 macros with 
Linux.   It would be better if null macros were outside the 
DTRACE_ENABLED condition, but that copies all of the USDT1 macros 
again.  Someone should clean this up.
>
>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/
> Also thanks for picking up the buildtree.make changes for bsd and
> solaris. Note that this version doesn't include the new testcase, don't
> know if that was intentional?

We can add testcases when BSD is supported (it's not yet).

Thanks,
Coleen
>
> Cheers,
>
> Mark

From John.Coomes at oracle.com  Mon Oct  8 15:07:39 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Mon, 8 Oct 2012 15:07:39 -0700
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <20595.20140.54.570911@oracle.com>

Vote: yes

-John

From mikael.vidstedt at oracle.com  Mon Oct  8 17:30:33 2012
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 08 Oct 2012 17:30:33 -0700
Subject: RFR (S): 7197424: update copyright year to match last edit in jdk8
	hotspot repository
Message-ID: <50737029.9010900@oracle.com>


All,

Can I please get a couple of reviews of the below change?

Don't be scared by the size of the change, even though it touches many 
files (271 to be exact) the change is the same for all of them - 
updating the copyright year in the header. The change was created using 
the make/scripts/update_copyright_year.sh script from the JDK.

http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/

Thanks,
Mikael


From coleen.phillimore at oracle.com  Mon Oct  8 17:36:49 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Oct 2012 20:36:49 -0400
Subject: Request for Review: Conditionalize source so that functionality
	can be easily included or excluded
In-Reply-To: <506EF5E4.7070107@oracle.com>
References: <506EF5E4.7070107@oracle.com>
Message-ID: <507371A1.3000409@oracle.com>


Hi Joe,

Did you take out the Windows "kernel" build with this change?   If so, 
there are still code which refers to kernel in 
http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/make/Makefile.html which 
should be removed.

In make/Makefile, the COMMON_VM_*_TARGETS is what caused the kernel to 
be built with jprt.   This was pretty useful so that people didn't 
inadvertently break the kernel build.   I think you should add minimal1 
to this list instead now so that the same doesn't happen with minimal vm.

In 
http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/src/share/vm/code/nmethod.cpp.udiff.html

Do you not need the conditional compilation because 
JvmtiExport::has_redefined_a_class() is included and always returns false?

If kernel is completely removed, there's some code you can remove in 
systemDictionary.cpp as well.   I think that's the last of the kernel code.

Rest looks good.
Coleen

On 10/5/2012 10:59 AM, Joe Provino wrote:
> The latest and hopefully final webrev is here:
>
> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10 
> <http://cr.openjdk.java.net/%7Ejprovino/7189254/webrev.10/>
>
> The changes are to make/{linux,bsd}/gcc.make to ensure that
> CFLAGS and OPT_CFLAGS behave the way they did before any changes.
>
> joe
>

From coleen.phillimore at oracle.com  Mon Oct  8 17:51:39 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Oct 2012 20:51:39 -0400
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50737029.9010900@oracle.com>
References: <50737029.9010900@oracle.com>
Message-ID: <5073751B.8030202@oracle.com>


I thought the copyright header was only updated if the file was changed 
in 2012.  Is this the case with these files?
Thanks,
Coleen

On 10/8/2012 8:30 PM, Mikael Vidstedt wrote:
>
> All,
>
> Can I please get a couple of reviews of the below change?
>
> Don't be scared by the size of the change, even though it touches many 
> files (271 to be exact) the change is the same for all of them - 
> updating the copyright year in the header. The change was created 
> using the make/scripts/update_copyright_year.sh script from the JDK.
>
> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>
> Thanks,
> Mikael
>

From mikael.vidstedt at oracle.com  Mon Oct  8 18:05:37 2012
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 08 Oct 2012 18:05:37 -0700
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <5073751B.8030202@oracle.com>
References: <50737029.9010900@oracle.com> <5073751B.8030202@oracle.com>
Message-ID: <50737861.40508@oracle.com>


Yes, the script extracts all the change sets from the current year and 
updates the copyright year for the files touched by those (and only 
those) change sets.

Cheers,
Mikael

On 10/8/2012 5:51 PM, Coleen Phillimore wrote:
>
> I thought the copyright header was only updated if the file was 
> changed in 2012.  Is this the case with these files?
> Thanks,
> Coleen
>
> On 10/8/2012 8:30 PM, Mikael Vidstedt wrote:
>>
>> All,
>>
>> Can I please get a couple of reviews of the below change?
>>
>> Don't be scared by the size of the change, even though it touches 
>> many files (271 to be exact) the change is the same for all of them - 
>> updating the copyright year in the header. The change was created 
>> using the make/scripts/update_copyright_year.sh script from the JDK.
>>
>> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>>
>> Thanks,
>> Mikael
>>


From tao.mao at oracle.com  Mon Oct  8 18:28:39 2012
From: tao.mao at oracle.com (Tao Mao)
Date: Mon, 08 Oct 2012 18:28:39 -0700
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50737861.40508@oracle.com>
References: <50737029.9010900@oracle.com> <5073751B.8030202@oracle.com>
	<50737861.40508@oracle.com>
Message-ID: <50737DC7.10003@oracle.com>

followup question:
Does one who modifies the files have the responsibility to update the 
copyright year? Is it supposed to be done this way?

Thanks.
Tao

On 2012/10/8 18:05, Mikael Vidstedt wrote:
>
> Yes, the script extracts all the change sets from the current year and 
> updates the copyright year for the files touched by those (and only 
> those) change sets.
>
> Cheers,
> Mikael
>
> On 10/8/2012 5:51 PM, Coleen Phillimore wrote:
>>
>> I thought the copyright header was only updated if the file was 
>> changed in 2012.  Is this the case with these files?
>> Thanks,
>> Coleen
>>
>> On 10/8/2012 8:30 PM, Mikael Vidstedt wrote:
>>>
>>> All,
>>>
>>> Can I please get a couple of reviews of the below change?
>>>
>>> Don't be scared by the size of the change, even though it touches 
>>> many files (271 to be exact) the change is the same for all of them 
>>> - updating the copyright year in the header. The change was created 
>>> using the make/scripts/update_copyright_year.sh script from the JDK.
>>>
>>> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>>>
>>> Thanks,
>>> Mikael
>>>
>


From david.holmes at oracle.com  Mon Oct  8 18:42:56 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Oct 2012 11:42:56 +1000
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50737029.9010900@oracle.com>
References: <50737029.9010900@oracle.com>
Message-ID: <50738120.60903@oracle.com>

Hi Mikael,

On 9/10/2012 10:30 AM, Mikael Vidstedt wrote:
> Can I please get a couple of reviews of the below change?
>
> Don't be scared by the size of the change, even though it touches many
> files (271 to be exact) the change is the same for all of them -
> updating the copyright year in the header. The change was created using
> the make/scripts/update_copyright_year.sh script from the JDK.
>
> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/

I've verified that the copyrights have been updated to 2012.

I can't (well won't :) ) validate that they should have been updated to 
2012. I did check a couple and saw that JSR-292 changes seem t be 
involved a lot. ;-)

Personally I'd prefer to see file copyrights always updated at 
modification time (preferably automagically!) rather than in bulk later 
- as later no one is validating the change. Hotspot always tended to 
work this way in the past, whereas the JDK did/does not. There are pros 
and cons either way.

Cheers,
David

> Thanks,
> Mikael
>

From david.holmes at oracle.com  Mon Oct  8 20:57:16 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Oct 2012 13:57:16 +1000
Subject: Request for Review: Conditionalize source so that functionality
	can be easily included or excluded
In-Reply-To: <507371A1.3000409@oracle.com>
References: <506EF5E4.7070107@oracle.com> <507371A1.3000409@oracle.com>
Message-ID: <5073A09C.7070408@oracle.com>

Hi Coleen,

If I may reply in Joe's stead ...

On 9/10/2012 10:36 AM, Coleen Phillimore wrote:
>
> Hi Joe,
>
> Did you take out the Windows "kernel" build with this change? If so,
> there are still code which refers to kernel in
> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/make/Makefile.html which
> should be removed.

"kernel" has not been completely eradicated but it is no longer built at 
all. Full eradication is a later clean up. (Joe: do we have a CR for 
that yet?)

> In make/Makefile, the COMMON_VM_*_TARGETS is what caused the kernel to
> be built with jprt. This was pretty useful so that people didn't
> inadvertently break the kernel build. I think you should add minimal1 to
> this list instead now so that the same doesn't happen with minimal vm.

The minimal VM is not intended to always be built, but will be, for 
example, as part of building SE Embedded, hence JPRT will be testing the 
minimal VM build works.

Going forward, in the new build system which VMs get built is determined 
by the JVM_VARIANT_* variables, which in turn are set at configure time. 
So the whole notion of "common" VM targets will be going away soon. 
(There are default settings for these variables for non-configure based 
builds.)

> In
> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/src/share/vm/code/nmethod.cpp.udiff.html
>
>
> Do you not need the conditional compilation because
> JvmtiExport::has_redefined_a_class() is included and always returns false?

Good catch - the conditional compilation is not needed there. (The same 
function is unguarded elsewhere.)

> If kernel is completely removed, there's some code you can remove in
> systemDictionary.cpp as well. I think that's the last of the kernel code.

See above - kernel not completely eradicated.

Thanks,
David
-----

> Rest looks good.
> Coleen
>
> On 10/5/2012 10:59 AM, Joe Provino wrote:
>> The latest and hopefully final webrev is here:
>>
>> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10
>> <http://cr.openjdk.java.net/%7Ejprovino/7189254/webrev.10/>
>>
>> The changes are to make/{linux,bsd}/gcc.make to ensure that
>> CFLAGS and OPT_CFLAGS behave the way they did before any changes.
>>
>> joe
>>

From rickard.backman at oracle.com  Mon Oct  8 22:54:39 2012
From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=)
Date: Tue, 9 Oct 2012 07:54:39 +0200
Subject: CFV: New HSX Committer: Nils Eliasson
In-Reply-To: <506F592E.1060602@oracle.com>
References: <506F592E.1060602@oracle.com>
Message-ID: <3A0E52EF-AEF2-4ABC-B9B3-D0644B224C68@oracle.com>

Vote: yes

/R

On Oct 6, 2012, at 12:03 AM, Vladimir Kozlov wrote:

> I hereby nominate Nils Eliasson (OpenJDK user name: neliasso) to HSX Committer.
> 
> Nils is a member of the Hotspot Compiler group. Prior to joining Hotspot development, he worked on JRockit VM in Oracle. He contributed 8 changesets to HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=nils.eliasson
> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a9b9cfcef41
> 
> Votes are due by Oct 19, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From mjw at redhat.com  Tue Oct  9 01:04:16 2012
From: mjw at redhat.com (Mark Wielaard)
Date: Tue, 09 Oct 2012 10:04:16 +0200
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <50734AA8.6060401@oracle.com>
References: <5065A634.1050600@oracle.com> <50698B21.7030208@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
	<1349434806.3478.10.camel@springer.wildebeest.org>
	<50734AA8.6060401@oracle.com>
Message-ID: <1349769856.9698.9.camel@springer.wildebeest.org>

On Mon, 2012-10-08 at 17:50 -0400, Coleen Phillimore wrote:
> On 10/5/2012 7:00 AM, Mark Wielaard wrote:
> > On Thu, 2012-10-04 at 17:30 -0400, Coleen Phillimore wrote:
> >> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/
> > Also thanks for picking up the buildtree.make changes for bsd and
> > solaris. Note that this version doesn't include the new testcase, don't
> > know if that was intentional?
> 
> We can add testcases when BSD is supported (it's not yet).

Sorry, we might be talking past each other. I wasn't suggesting new test
cases were needed for BSD. Just wanted to mention that 7170638_5 was
missing test/serviceability/7170638/SDTProbesGNULinuxTest.sh which was
in 7170638_4.

Cheers,

Mark

From joseph.provino at oracle.com  Tue Oct  9 06:24:33 2012
From: joseph.provino at oracle.com (Joe Provino)
Date: Tue, 09 Oct 2012 09:24:33 -0400
Subject: Request for Review: Conditionalize source so that functionality
	can be easily included or excluded
In-Reply-To: <5073A09C.7070408@oracle.com>
References: <506EF5E4.7070107@oracle.com> <507371A1.3000409@oracle.com>
	<5073A09C.7070408@oracle.com>
Message-ID: <50742591.7010500@oracle.com>



On 10/8/2012 11:57 PM, David Holmes wrote:
> Hi Coleen,
>
> If I may reply in Joe's stead ...

David, thanks for replying.

Comments inline...

>
> On 9/10/2012 10:36 AM, Coleen Phillimore wrote:
>>
>> Hi Joe,
>>
>> Did you take out the Windows "kernel" build with this change? If so,
>> there are still code which refers to kernel in
>> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/make/Makefile.html 
>> which
>> should be removed.
>
> "kernel" has not been completely eradicated but it is no longer built 
> at all. Full eradication is a later clean up. (Joe: do we have a CR 
> for that yet?)

Not that I know of.  I'll do that.

>
>> In make/Makefile, the COMMON_VM_*_TARGETS is what caused the kernel to
>> be built with jprt. This was pretty useful so that people didn't
>> inadvertently break the kernel build. I think you should add minimal1 to
>> this list instead now so that the same doesn't happen with minimal vm.
>
> The minimal VM is not intended to always be built, but will be, for 
> example, as part of building SE Embedded, hence JPRT will be testing 
> the minimal VM build works.
>
> Going forward, in the new build system which VMs get built is 
> determined by the JVM_VARIANT_* variables, which in turn are set at 
> configure time. So the whole notion of "common" VM targets will be 
> going away soon. (There are default settings for these variables for 
> non-configure based builds.)
>
>> In
>> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/src/share/vm/code/nmethod.cpp.udiff.html 
>>
>>
>>
>> Do you not need the conditional compilation because
>> JvmtiExport::has_redefined_a_class() is included and always returns 
>> false?
>
> Good catch - the conditional compilation is not needed there. (The 
> same function is unguarded elsewhere.)

I'll get rid of the unnecessary conditional.

>
>> If kernel is completely removed, there's some code you can remove in
>> systemDictionary.cpp as well. I think that's the last of the kernel 
>> code.
>
> See above - kernel not completely eradicated.
>
> Thanks,
> David
> -----
>
>> Rest looks good.

Thanks for the review!

joe

>> Coleen
>>
>> On 10/5/2012 10:59 AM, Joe Provino wrote:
>>> The latest and hopefully final webrev is here:
>>>
>>> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10
>>> <http://cr.openjdk.java.net/%7Ejprovino/7189254/webrev.10/>
>>>
>>> The changes are to make/{linux,bsd}/gcc.make to ensure that
>>> CFLAGS and OPT_CFLAGS behave the way they did before any changes.
>>>
>>> joe
>>>

From coleen.phillimore at oracle.com  Tue Oct  9 06:27:27 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Oct 2012 09:27:27 -0400
Subject: Request for review 7170638: Use DTRACE_PROBE[N] in JNI Set and
	SetStatic Field.
In-Reply-To: <1349769856.9698.9.camel@springer.wildebeest.org>
References: <5065A634.1050600@oracle.com>
	<1349115632.2682.122.camel@springer.wildebeest.org>
	<5069F3E8.10600@oracle.com>
	<1349121739.2682.128.camel@springer.wildebeest.org>
	<506A01D1.8020604@oracle.com>
	<20121001212426.GA7120@toonder.wildebeest.org>
	<506A19B4.7040200@oracle.com>
	<90FAF470-4251-4D82-8E96-710424913EF2@oracle.com>
	<20121002085251.GA18223@toonder.wildebeest.org>
	<506B95AE.6070002@oracle.com>
	<1349256791.2682.163.camel@springer.wildebeest.org>
	<506C2D25.9020701@oracle.com>
	<1349268510.2682.180.camel@springer.wildebeest.org>
	<506C3706.90802@oracle.com>
	<1349275088.2682.200.camel@springer.wildebeest.org>
	<506CB3A2.7090208@oracle.com> <506CC3DB.3050104@oracle.com>
	<506D7670.9040103@oracle.com> <506D8F53.5010609@oracle.com>
	<506D966B.1040406@oracle.com> <506DFFD9.8010902@oracle.com>
	<1349434806.3478.10.camel@springer.wildebeest.org>
	<50734AA8.6060401@oracle.com>
	<1349769856.9698.9.camel@springer.wildebeest.org>
Message-ID: <5074263F.5080504@oracle.com>


I wish I'd read that correctly because I forgot to hg add the test in 
the other repository that I created so I didn't check it in.
I'll file a new bug and do so.  Crap.
thanks,
Coleen

On 10/9/2012 4:04 AM, Mark Wielaard wrote:
> On Mon, 2012-10-08 at 17:50 -0400, Coleen Phillimore wrote:
>> On 10/5/2012 7:00 AM, Mark Wielaard wrote:
>>> On Thu, 2012-10-04 at 17:30 -0400, Coleen Phillimore wrote:
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7170638_5/
>>> Also thanks for picking up the buildtree.make changes for bsd and
>>> solaris. Note that this version doesn't include the new testcase, don't
>>> know if that was intentional?
>> We can add testcases when BSD is supported (it's not yet).
> Sorry, we might be talking past each other. I wasn't suggesting new test
> cases were needed for BSD. Just wanted to mention that 7170638_5 was
> missing test/serviceability/7170638/SDTProbesGNULinuxTest.sh which was
> in 7170638_4.
>
> Cheers,
>
> Mark

From coleen.phillimore at oracle.com  Tue Oct  9 06:54:12 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Oct 2012 09:54:12 -0400
Subject: Request for review 8000622: Forgot to hg add and check in test for
	JDK-7170638
Message-ID: <50742C84.4070106@oracle.com>

Summary: add the test
Contributed-by: Mark Wielaard <mjw at redhat.com>

Thanks,
Coleen

From azeem.jiva at oracle.com  Tue Oct  9 06:58:04 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Tue, 09 Oct 2012 08:58:04 -0500
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50737029.9010900@oracle.com>
References: <50737029.9010900@oracle.com>
Message-ID: <50742D6C.90203@oracle.com>

Doesn't it make more sense to wait a few months and update everything to 
2013?

On 10/08/2012 07:30 PM, Mikael Vidstedt wrote:
>
> All,
>
> Can I please get a couple of reviews of the below change?
>
> Don't be scared by the size of the change, even though it touches many 
> files (271 to be exact) the change is the same for all of them - 
> updating the copyright year in the header. The change was created 
> using the make/scripts/update_copyright_year.sh script from the JDK.
>
> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>
> Thanks,
> Mikael
>

-- 
Azeem Jiva
@javawithjiva


From coleen.phillimore at oracle.com  Tue Oct  9 07:00:50 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Oct 2012 10:00:50 -0400
Subject: Request for review 8000622: Forgot to hg add and check in test
	for JDK-7170638
In-Reply-To: <50742C84.4070106@oracle.com>
References: <50742C84.4070106@oracle.com>
Message-ID: <50742E12.2030109@oracle.com>


open webrev at http://cr.openjdk.java.net/~coleenp/8000622/

On 10/9/2012 9:54 AM, Coleen Phillimore wrote:
> Summary: add the test
> Contributed-by: Mark Wielaard <mjw at redhat.com>
>
> Thanks,
> Coleen

From keith.mcguigan at oracle.com  Tue Oct  9 07:07:43 2012
From: keith.mcguigan at oracle.com (keith mcguigan)
Date: Tue, 09 Oct 2012 10:07:43 -0400
Subject: Request for review 8000622: Forgot to hg add and check in test
	for JDK-7170638
In-Reply-To: <50742E12.2030109@oracle.com>
References: <50742C84.4070106@oracle.com> <50742E12.2030109@oracle.com>
Message-ID: <50742FAF.7030105@oracle.com>

ok

On 10/9/2012 10:00 AM, Coleen Phillimore wrote:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8000622/
>
> On 10/9/2012 9:54 AM, Coleen Phillimore wrote:
>> Summary: add the test
>> Contributed-by: Mark Wielaard <mjw at redhat.com>
>>
>> Thanks,
>> Coleen

From coleen.phillimore at oracle.com  Tue Oct  9 07:12:27 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Oct 2012 10:12:27 -0400
Subject: Request for Review: Conditionalize source so that functionality
	can be easily included or excluded
In-Reply-To: <50742591.7010500@oracle.com>
References: <506EF5E4.7070107@oracle.com> <507371A1.3000409@oracle.com>
	<5073A09C.7070408@oracle.com> <50742591.7010500@oracle.com>
Message-ID: <507430CB.8020007@oracle.com>


>>
>> On 9/10/2012 10:36 AM, Coleen Phillimore wrote:
>>>
>>> Hi Joe,
>>>
>>> Did you take out the Windows "kernel" build with this change? If so,
>>> there are still code which refers to kernel in
>>> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/make/Makefile.html 
>>> which
>>> should be removed.
>>
>> "kernel" has not been completely eradicated but it is no longer built 
>> at all. Full eradication is a later clean up. (Joe: do we have a CR 
>> for that yet?)
>
> Not that I know of.  I'll do that.

Okay, this is fine.  Please file a bug and send me the number.

Thanks,
Coleen
>
>>
>>> In make/Makefile, the COMMON_VM_*_TARGETS is what caused the kernel to
>>> be built with jprt. This was pretty useful so that people didn't
>>> inadvertently break the kernel build. I think you should add 
>>> minimal1 to
>>> this list instead now so that the same doesn't happen with minimal vm.
>>
>> The minimal VM is not intended to always be built, but will be, for 
>> example, as part of building SE Embedded, hence JPRT will be testing 
>> the minimal VM build works.
>>
>> Going forward, in the new build system which VMs get built is 
>> determined by the JVM_VARIANT_* variables, which in turn are set at 
>> configure time. So the whole notion of "common" VM targets will be 
>> going away soon. (There are default settings for these variables for 
>> non-configure based builds.)
>>
>>> In
>>> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10/src/share/vm/code/nmethod.cpp.udiff.html 
>>>
>>>
>>>
>>> Do you not need the conditional compilation because
>>> JvmtiExport::has_redefined_a_class() is included and always returns 
>>> false?
>>
>> Good catch - the conditional compilation is not needed there. (The 
>> same function is unguarded elsewhere.)
>
> I'll get rid of the unnecessary conditional.
>
>>
>>> If kernel is completely removed, there's some code you can remove in
>>> systemDictionary.cpp as well. I think that's the last of the kernel 
>>> code.
>>
>> See above - kernel not completely eradicated.
>>
>> Thanks,
>> David
>> -----
>>
>>> Rest looks good.
>
> Thanks for the review!
>
> joe
>
>>> Coleen
>>>
>>> On 10/5/2012 10:59 AM, Joe Provino wrote:
>>>> The latest and hopefully final webrev is here:
>>>>
>>>> http://cr.openjdk.java.net/~jprovino/7189254/webrev.10
>>>> <http://cr.openjdk.java.net/%7Ejprovino/7189254/webrev.10/>
>>>>
>>>> The changes are to make/{linux,bsd}/gcc.make to ensure that
>>>> CFLAGS and OPT_CFLAGS behave the way they did before any changes.
>>>>
>>>> joe
>>>>

From serguei.spitsyn at oracle.com  Tue Oct  9 09:24:58 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 09 Oct 2012 09:24:58 -0700
Subject: Request for review 8000622: Forgot to hg add and check in test
	for JDK-7170638
In-Reply-To: <50742E12.2030109@oracle.com>
References: <50742C84.4070106@oracle.com> <50742E12.2030109@oracle.com>
Message-ID: <50744FDA.4050000@oracle.com>

Looks good.

Thanks,
Serguei

On 10/9/12 7:00 AM, Coleen Phillimore wrote:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8000622/
>
> On 10/9/2012 9:54 AM, Coleen Phillimore wrote:
>> Summary: add the test
>> Contributed-by: Mark Wielaard <mjw at redhat.com>
>>
>> Thanks,
>> Coleen


From mikael.vidstedt at oracle.com  Tue Oct  9 09:53:10 2012
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 09 Oct 2012 09:53:10 -0700
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50742D6C.90203@oracle.com>
References: <50737029.9010900@oracle.com> <50742D6C.90203@oracle.com>
Message-ID: <50745676.5060305@oracle.com>


Just because we enter a new calendar year doesn't mean the copyright 
year should automatically be updated to 2013 - the year should reflect 
the year when the last actual change was made.

Cheers,
Mikael

On 10/9/2012 6:58 AM, Azeem Jiva wrote:
> Doesn't it make more sense to wait a few months and update everything 
> to 2013?
>
> On 10/08/2012 07:30 PM, Mikael Vidstedt wrote:
>>
>> All,
>>
>> Can I please get a couple of reviews of the below change?
>>
>> Don't be scared by the size of the change, even though it touches 
>> many files (271 to be exact) the change is the same for all of them - 
>> updating the copyright year in the header. The change was created 
>> using the make/scripts/update_copyright_year.sh script from the JDK.
>>
>> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>>
>> Thanks,
>> Mikael
>>
>


From mikael.vidstedt at oracle.com  Tue Oct  9 09:59:06 2012
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 09 Oct 2012 09:59:06 -0700
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50738120.60903@oracle.com>
References: <50737029.9010900@oracle.com> <50738120.60903@oracle.com>
Message-ID: <507457DA.4010907@oracle.com>


I also did a couple of additional verifications to make sure the script 
seemed to have done the right thing and it does indeed look correct.

I think there's been some work to see if we can have the update happen 
more or less automagically at modification time and I agree that if we 
could reduce the pain level it would be nice to do it that way, but just 
as you say there are pros and cons.

Thanks,
Mikael

On 10/8/2012 6:42 PM, David Holmes wrote:
> Hi Mikael,
>
> On 9/10/2012 10:30 AM, Mikael Vidstedt wrote:
>> Can I please get a couple of reviews of the below change?
>>
>> Don't be scared by the size of the change, even though it touches many
>> files (271 to be exact) the change is the same for all of them -
>> updating the copyright year in the header. The change was created using
>> the make/scripts/update_copyright_year.sh script from the JDK.
>>
>> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>
> I've verified that the copyrights have been updated to 2012.
>
> I can't (well won't :) ) validate that they should have been updated 
> to 2012. I did check a couple and saw that JSR-292 changes seem t be 
> involved a lot. ;-)
>
> Personally I'd prefer to see file copyrights always updated at 
> modification time (preferably automagically!) rather than in bulk 
> later - as later no one is validating the change. Hotspot always 
> tended to work this way in the past, whereas the JDK did/does not. 
> There are pros and cons either way.
>
> Cheers,
> David
>
>> Thanks,
>> Mikael
>>


From coleen.phillimore at oracle.com  Tue Oct  9 10:17:48 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Oct 2012 13:17:48 -0400
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <507457DA.4010907@oracle.com>
References: <50737029.9010900@oracle.com> <50738120.60903@oracle.com>
	<507457DA.4010907@oracle.com>
Message-ID: <50745C3C.3090203@oracle.com>


Mikael,  This looks good.

Coleen

On 10/9/2012 12:59 PM, Mikael Vidstedt wrote:
>
> I also did a couple of additional verifications to make sure the 
> script seemed to have done the right thing and it does indeed look 
> correct.
>
> I think there's been some work to see if we can have the update happen 
> more or less automagically at modification time and I agree that if we 
> could reduce the pain level it would be nice to do it that way, but 
> just as you say there are pros and cons.
>
> Thanks,
> Mikael
>
> On 10/8/2012 6:42 PM, David Holmes wrote:
>> Hi Mikael,
>>
>> On 9/10/2012 10:30 AM, Mikael Vidstedt wrote:
>>> Can I please get a couple of reviews of the below change?
>>>
>>> Don't be scared by the size of the change, even though it touches many
>>> files (271 to be exact) the change is the same for all of them -
>>> updating the copyright year in the header. The change was created using
>>> the make/scripts/update_copyright_year.sh script from the JDK.
>>>
>>> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>>
>> I've verified that the copyrights have been updated to 2012.
>>
>> I can't (well won't :) ) validate that they should have been updated 
>> to 2012. I did check a couple and saw that JSR-292 changes seem t be 
>> involved a lot. ;-)
>>
>> Personally I'd prefer to see file copyrights always updated at 
>> modification time (preferably automagically!) rather than in bulk 
>> later - as later no one is validating the change. Hotspot always 
>> tended to work this way in the past, whereas the JDK did/does not. 
>> There are pros and cons either way.
>>
>> Cheers,
>> David
>>
>>> Thanks,
>>> Mikael
>>>
>

From mikael.vidstedt at oracle.com  Tue Oct  9 10:46:00 2012
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 09 Oct 2012 10:46:00 -0700
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50745C3C.3090203@oracle.com>
References: <50737029.9010900@oracle.com> <50738120.60903@oracle.com>
	<507457DA.4010907@oracle.com> <50745C3C.3090203@oracle.com>
Message-ID: <507462D8.2040303@oracle.com>


Thanks Coleen!

/Mikael

On 10/9/2012 10:17 AM, Coleen Phillimore wrote:
>
> Mikael,  This looks good.
>
> Coleen
>
> On 10/9/2012 12:59 PM, Mikael Vidstedt wrote:
>>
>> I also did a couple of additional verifications to make sure the 
>> script seemed to have done the right thing and it does indeed look 
>> correct.
>>
>> I think there's been some work to see if we can have the update 
>> happen more or less automagically at modification time and I agree 
>> that if we could reduce the pain level it would be nice to do it that 
>> way, but just as you say there are pros and cons.
>>
>> Thanks,
>> Mikael
>>
>> On 10/8/2012 6:42 PM, David Holmes wrote:
>>> Hi Mikael,
>>>
>>> On 9/10/2012 10:30 AM, Mikael Vidstedt wrote:
>>>> Can I please get a couple of reviews of the below change?
>>>>
>>>> Don't be scared by the size of the change, even though it touches many
>>>> files (271 to be exact) the change is the same for all of them -
>>>> updating the copyright year in the header. The change was created 
>>>> using
>>>> the make/scripts/update_copyright_year.sh script from the JDK.
>>>>
>>>> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
>>>
>>> I've verified that the copyrights have been updated to 2012.
>>>
>>> I can't (well won't :) ) validate that they should have been updated 
>>> to 2012. I did check a couple and saw that JSR-292 changes seem t be 
>>> involved a lot. ;-)
>>>
>>> Personally I'd prefer to see file copyrights always updated at 
>>> modification time (preferably automagically!) rather than in bulk 
>>> later - as later no one is validating the change. Hotspot always 
>>> tended to work this way in the past, whereas the JDK did/does not. 
>>> There are pros and cons either way.
>>>
>>> Cheers,
>>> David
>>>
>>>> Thanks,
>>>> Mikael
>>>>
>>


From stefan.karlsson at oracle.com  Tue Oct  9 13:30:17 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 09 Oct 2012 22:30:17 +0200
Subject: Review request: 8000659: NPG: ClassCastExceptions are unexpectedly
	thrown when testing nashorn
Message-ID: <50748959.6030003@oracle.com>

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

SystemDictionary::always_strong_oops_do() is missing a call to 
invoke_method_table()->oops_do(). 
SystemDictionary::always_strong_oops_do is used during marking when 
ClassUnloading is enabled. Because of this HotSpot fail to mark the 
objects in this table as alive.

StefanK

From keith.mcguigan at oracle.com  Tue Oct  9 13:36:37 2012
From: keith.mcguigan at oracle.com (keith mcguigan)
Date: Tue, 09 Oct 2012 16:36:37 -0400
Subject: Review request: 8000659: NPG: ClassCastExceptions are unexpectedly
	thrown when testing nashorn
In-Reply-To: <50748959.6030003@oracle.com>
References: <50748959.6030003@oracle.com>
Message-ID: <50748AD5.1080808@oracle.com>


Looks good!

--
- Keith

On 10/9/2012 4:30 PM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8000659/webrev/
>
> SystemDictionary::always_strong_oops_do() is missing a call to
> invoke_method_table()->oops_do().
> SystemDictionary::always_strong_oops_do is used during marking when
> ClassUnloading is enabled. Because of this HotSpot fail to mark the
> objects in this table as alive.
>
> StefanK

From coleen.phillimore at oracle.com  Tue Oct  9 13:49:00 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Oct 2012 16:49:00 -0400
Subject: Review request: 8000659: NPG: ClassCastExceptions are unexpectedly
	thrown when testing nashorn
In-Reply-To: <50748959.6030003@oracle.com>
References: <50748959.6030003@oracle.com>
Message-ID: <50748DBC.7000302@oracle.com>


Looks good.
Coleen

On 10/9/2012 4:30 PM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8000659/webrev/
>
> SystemDictionary::always_strong_oops_do() is missing a call to 
> invoke_method_table()->oops_do(). 
> SystemDictionary::always_strong_oops_do is used during marking when 
> ClassUnloading is enabled. Because of this HotSpot fail to mark the 
> objects in this table as alive.
>
> StefanK

From jiangli.zhou at oracle.com  Tue Oct  9 16:26:31 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 09 Oct 2012 16:26:31 -0700
Subject: Review request: 8000459: assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
Message-ID: <5074B2A7.6050503@oracle.com>

Please review following fix for 8000459:

   http://cr.openjdk.java.net/~jiangli/8000459/webrev/

With JSR292, a constant pool String entry could be patched to a 
non-string oop. The assert in VM_HeapWalkOperation::iterate_over_class() 
needs to be adjusted to reflect that.

Thanks,

Jiangli

From david.holmes at oracle.com  Tue Oct  9 17:09:06 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Oct 2012 10:09:06 +1000
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074B2A7.6050503@oracle.com>
References: <5074B2A7.6050503@oracle.com>
Message-ID: <5074BCA2.9090906@oracle.com>

On 10/10/2012 9:26 AM, Jiangli Zhou wrote:
> Please review following fix for 8000459:
>
> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>
> With JSR292, a constant pool String entry could be patched to a
> non-string oop. The assert in VM_HeapWalkOperation::iterate_over_class()
> needs to be adjusted to reflect that.

Looks okay to me.

David
-----

> Thanks,
>
> Jiangli

From jiangli.zhou at oracle.com  Tue Oct  9 17:17:45 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 09 Oct 2012 17:17:45 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074BCA2.9090906@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074BCA2.9090906@oracle.com>
Message-ID: <5074BEA9.2080709@oracle.com>

Thanks, David!

Jiangli

On 10/09/2012 05:09 PM, David Holmes wrote:
> On 10/10/2012 9:26 AM, Jiangli Zhou wrote:
>> Please review following fix for 8000459:
>>
>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>
>> With JSR292, a constant pool String entry could be patched to a
>> non-string oop. The assert in VM_HeapWalkOperation::iterate_over_class()
>> needs to be adjusted to reflect that.
>
> Looks okay to me.
>
> David
> -----
>
>> Thanks,
>>
>> Jiangli


From serguei.spitsyn at oracle.com  Tue Oct  9 18:05:55 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 09 Oct 2012 18:05:55 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074B2A7.6050503@oracle.com>
References: <5074B2A7.6050503@oracle.com>
Message-ID: <5074C9F3.3000702@oracle.com>

Hi Jiangli,

I'm not very familiar with the pseudo strings, and so, just have a question:

*src/share/vm/prims/jvmtiTagMap.cpp*

2927             entry = pool->resolved_string_at(i);
2928             assert(java_lang_String::is_instance(entry) ||
2929                    pool->is_pseudo_string_at(i), "must be string");

I have a little of doubt the above is correct.

What value the "entry" will have in a case of pseudo string cp entry?
Just want to understand what constant pool reference will be reported.
Do you see all related failing tests passed?

Would something like the following be more accurate ?
    entry = pool->is_pseudo_string_at(i) ?
                pool->pseudo_string_at(i, cp_to_object_index(i)) :
                pool->resolved_string_at(i);
assert(java_lang_String::is_instance(entry));

In this case, a reference from CP to string is reported regardless it is 
pseudo string or not.


Thanks,
Serguei

On 10/9/12 4:26 PM, Jiangli Zhou wrote:
> Please review following fix for 8000459:
>
>   http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>
> With JSR292, a constant pool String entry could be patched to a 
> non-string oop. The assert in 
> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to 
> reflect that.
>
> Thanks,
>
> Jiangli


From david.holmes at oracle.com  Tue Oct  9 18:46:07 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Oct 2012 11:46:07 +1000
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074C9F3.3000702@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074C9F3.3000702@oracle.com>
Message-ID: <5074D35F.1080803@oracle.com>

On 10/10/2012 11:05 AM, serguei.spitsyn at oracle.com wrote:
> Hi Jiangli,
>
> I'm not very familiar with the pseudo strings, and so, just have a
> question:
>
> *src/share/vm/prims/jvmtiTagMap.cpp*
>
> 2927 entry = pool->resolved_string_at(i);
> 2928 assert(java_lang_String::is_instance(entry) ||
> 2929 pool->is_pseudo_string_at(i), "must be string");
>
> I have a little of doubt the above is correct.
>
> What value the "entry" will have in a case of pseudo string cp entry?
> Just want to understand what constant pool reference will be reported.

The pool stores strings and pseudo-strings in the same way. So 
pool->resolved_string_at(i) and pool->pseudo_string_at(i, 
cp_to_object_index(i)) return the same thing.

So entry is either a real string or a pseudo-string - hence the assert 
checks for either one.

There were a number of ways this code could have been modified to handle 
this, but augmenting the assert was simplest.

> Do you see all related failing tests passed?
>
> Would something like the following be more accurate ?
> entry = pool->is_pseudo_string_at(i) ?
> pool->pseudo_string_at(i, cp_to_object_index(i)) :
> pool->resolved_string_at(i);

entry is the same no matter which path is taken.

> assert(java_lang_String::is_instance(entry));

That assert fails if entry was a pseudo-string.

David
-----

> In this case, a reference from CP to string is reported regardless it is
> pseudo string or not.
>
>
> Thanks,
> Serguei
>
> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>> Please review following fix for 8000459:
>>
>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>
>> With JSR292, a constant pool String entry could be patched to a
>> non-string oop. The assert in
>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to
>> reflect that.
>>
>> Thanks,
>>
>> Jiangli
>

From vladimir.kozlov at oracle.com  Tue Oct  9 19:12:12 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Oct 2012 19:12:12 -0700
Subject: CFV: New HSX Committer: Vladimir Ivanov
Message-ID: <5074D97C.2000604@oracle.com>

I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX Committer.

Vladimir is a member of the Hotspot Compiler group. Prior to joining Hotspot
development, he worked in Hotspot SQE group. He contributed 8 changesets to
HSX project and he is qualified to be committer [1]:

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov

Votes are due by Oct 23, 2012.

Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Thanks,
Vladimir Kozlov

[1] http://openjdk.java.net/projects/#project-committer
[2] http://openjdk.java.net/census#hsx
[3] http://openjdk.java.net/projects#committer-vote


From vladimir.kozlov at oracle.com  Tue Oct  9 19:39:17 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Oct 2012 19:39:17 -0700
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <5074DFD5.5090901@oracle.com>

Vote: yes

Vladimir Kozlov wrote:
> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX 
> Committer.
> 
> Vladimir is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 changesets to
> HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov 
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
> 
> Votes are due by Oct 23, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 

From serguei.spitsyn at oracle.com  Tue Oct  9 19:42:07 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 09 Oct 2012 19:42:07 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074D35F.1080803@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074C9F3.3000702@oracle.com>
	<5074D35F.1080803@oracle.com>
Message-ID: <5074E07F.4030506@oracle.com>

Got it. Thanks, David.
It means, pseudo string is not a java_lang_String.

Jiangli,
Thumbs up.

Thanks,
Serguei


On 10/9/12 6:46 PM, David Holmes wrote:
> On 10/10/2012 11:05 AM, serguei.spitsyn at oracle.com wrote:
>> Hi Jiangli,
>>
>> I'm not very familiar with the pseudo strings, and so, just have a
>> question:
>>
>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>
>> 2927 entry = pool->resolved_string_at(i);
>> 2928 assert(java_lang_String::is_instance(entry) ||
>> 2929 pool->is_pseudo_string_at(i), "must be string");
>>
>> I have a little of doubt the above is correct.
>>
>> What value the "entry" will have in a case of pseudo string cp entry?
>> Just want to understand what constant pool reference will be reported.
>
> The pool stores strings and pseudo-strings in the same way. So 
> pool->resolved_string_at(i) and pool->pseudo_string_at(i, 
> cp_to_object_index(i)) return the same thing.
>
> So entry is either a real string or a pseudo-string - hence the assert 
> checks for either one.
>
> There were a number of ways this code could have been modified to 
> handle this, but augmenting the assert was simplest.
>
>> Do you see all related failing tests passed?
>>
>> Would something like the following be more accurate ?
>> entry = pool->is_pseudo_string_at(i) ?
>> pool->pseudo_string_at(i, cp_to_object_index(i)) :
>> pool->resolved_string_at(i);
>
> entry is the same no matter which path is taken.
>
>> assert(java_lang_String::is_instance(entry));
>
> That assert fails if entry was a pseudo-string.
>
> David
> -----
>
>> In this case, a reference from CP to string is reported regardless it is
>> pseudo string or not.
>>
>>
>> Thanks,
>> Serguei
>>
>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>> Please review following fix for 8000459:
>>>
>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>
>>> With JSR292, a constant pool String entry could be patched to a
>>> non-string oop. The assert in
>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to
>>> reflect that.
>>>
>>> Thanks,
>>>
>>> Jiangli
>>


From john.r.rose at oracle.com  Tue Oct  9 21:35:16 2012
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 9 Oct 2012 21:35:16 -0700
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <10DDC444-11F8-4157-9C26-EEA1C4A85B3B@oracle.com>

Vote: yes

From david.holmes at oracle.com  Tue Oct  9 22:10:58 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Oct 2012 15:10:58 +1000
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <50750362.3070500@oracle.com>

Vote: yes

David

On 10/10/2012 12:12 PM, Vladimir Kozlov wrote:
> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX
> Committer.
>
> Vladimir is a member of the Hotspot Compiler group. Prior to joining
> Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 changesets to
> HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
>
> Votes are due by Oct 23, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.
> Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From John.Coomes at oracle.com  Tue Oct  9 22:36:18 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Tue, 9 Oct 2012 22:36:18 -0700
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <20597.2386.892012.204471@oracle.com>

Vote: yes

-John

From bengt.rutisson at oracle.com  Tue Oct  9 22:57:59 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 10 Oct 2012 07:57:59 +0200
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <50750E67.5090705@oracle.com>


Vote: yes

Bengt

On 2012-10-10 04:12, Vladimir Kozlov wrote:
> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX 
> Committer.
>
> Vladimir is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 
> changesets to
> HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov 
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
>
> Votes are due by Oct 23, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>


From roland.westrelin at oracle.com  Wed Oct 10 00:49:42 2012
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 10 Oct 2012 09:49:42 +0200
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <70FF9C58-2586-487F-9182-0A9D47A8AC7F@oracle.com>

Vote: yes

Roland.

From jesper.wilhelmsson at oracle.com  Wed Oct 10 01:46:16 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 10 Oct 2012 10:46:16 +0200
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <507535D8.70101@oracle.com>

Vote: yes

/Jesper

On 2012-10-10 04:12, Vladimir Kozlov wrote:
> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX Committer.
>
> Vladimir is a member of the Hotspot Compiler group. Prior to joining Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 changesets to
> HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
>
> Votes are due by Oct 23, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From alejandro.murillo at oracle.com  Wed Oct 10 02:34:04 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 10 Oct 2012 03:34:04 -0600
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <5075410C.3030708@oracle.com>

Vote: yes

On 10/9/2012 8:12 PM, Vladimir Kozlov wrote:
> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX 
> Committer.
>
> Vladimir is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 
> changesets to
> HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov 
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
>
> Votes are due by Oct 23, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>


From keith.mcguigan at oracle.com  Wed Oct 10 03:04:35 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 10 Oct 2012 06:04:35 -0400
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <A106D6F0-BA0F-4A1F-B867-1F1756A61E84@oracle.com>

Vote: yes

On Oct 9, 2012, at 10:12 PM, Vladimir Kozlov wrote:

> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX Committer.
> 
> Vladimir is a member of the Hotspot Compiler group. Prior to joining Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 changesets to
> HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
> 
> Votes are due by Oct 23, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From karen.kinnear at oracle.com  Wed Oct 10 05:20:31 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 10 Oct 2012 08:20:31 -0400
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <E22A0A42-639E-48D9-943F-AAAD6CF204AD@oracle.com>

Vote: yes

Karen

On Oct 9, 2012, at 10:12 PM, Vladimir Kozlov wrote:

> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX Committer.
> 
> Vladimir is a member of the Hotspot Compiler group. Prior to joining Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 changesets to
> HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
> 
> Votes are due by Oct 23, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From kevin.walls at oracle.com  Wed Oct 10 05:53:30 2012
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 10 Oct 2012 13:53:30 +0100
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <50756FCA.9050401@oracle.com>

Vote: yes



From daniel.daugherty at oracle.com  Wed Oct 10 06:30:44 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 10 Oct 2012 07:30:44 -0600
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <50757884.5050404@oracle.com>

Vote: yes

Dan


On 10/9/12 8:12 PM, Vladimir Kozlov wrote:
> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX 
> Committer.
>
> Vladimir is a member of the Hotspot Compiler group. Prior to joining 
> Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 
> changesets to
> HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov 
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
>
> Votes are due by Oct 23, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this 
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From christian.tornqvist at oracle.com  Wed Oct 10 06:43:23 2012
From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=)
Date: Wed, 10 Oct 2012 06:43:23 -0700 (PDT)
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <263804e7-d560-4c0f-b246-68984e76663f@default>

Vote: yes

-----Original Message-----
From: Vladimir Kozlov 
Sent: den 10 oktober 2012 04:12
To: hotspot-dev
Subject: CFV: New HSX Committer: Vladimir Ivanov

I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX Committer.

Vladimir is a member of the Hotspot Compiler group. Prior to joining Hotspot development, he worked in Hotspot SQE group. He contributed 8 changesets to HSX project and he is qualified to be committer [1]:

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov

Votes are due by Oct 23, 2012.

Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Thanks,
Vladimir Kozlov

[1] http://openjdk.java.net/projects/#project-committer
[2] http://openjdk.java.net/census#hsx
[3] http://openjdk.java.net/projects#committer-vote


From jiangli.zhou at oracle.com  Wed Oct 10 09:37:44 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 10 Oct 2012 09:37:44 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074C9F3.3000702@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074C9F3.3000702@oracle.com>
Message-ID: <5075A458.7040900@oracle.com>

Hi Serguei,

Thanks for the review! Please see comments below.

On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
> Hi Jiangli,
>
> I'm not very familiar with the pseudo strings, and so, just have a 
> question:
>
> *src/share/vm/prims/jvmtiTagMap.cpp*
> 2927             entry = pool->resolved_string_at(i);
> 2928             assert(java_lang_String::is_instance(entry) ||
> 2929                    pool->is_pseudo_string_at(i), "must be string");
> I have a little of doubt the above is correct.
>
> What value the "entry" will have in a case of pseudo string cp entry?
> Just want to understand what constant pool reference will be reported.
> Do you see all related failing tests passed?
>
> Would something like the following be more accurate ?
>    entry = pool->is_pseudo_string_at(i) ?
>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>                pool->resolved_string_at(i);
> assert(java_lang_String::is_instance(entry));
>
> In this case, a reference from CP to string is reported regardless it 
> is pseudo string or not.

Those are very good questions. Here is an example of the specific case 
with a generated JSR292 java.lang.invoke.LambdaForm$MH class. The follow 
are two constant pool entries of the class. Entry 16 is a 
"sun/misc/Unsafe" String, which could be patched using a sun.misc.Unsafe 
klass oop.

         ...
         (0016) tag=Utf8 "sun/misc/Unsafe"
         (0017) tag=Class "sun/misc/Unsafe"
         ...

I discussed with John Rose about different ways to fix the assertion 
issue. The code you have above uses pseudo_string_at() to access the 
'entry', which is similar to one of the version we discussed. The 
current change was chosen as it's the simplest solution.

Thanks,

Jiangli
>
>
> Thanks,
> Serguei
>
> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>> Please review following fix for 8000459:
>>
>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>
>> With JSR292, a constant pool String entry could be patched to a 
>> non-string oop. The assert in 
>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to 
>> reflect that.
>>
>> Thanks,
>>
>> Jiangli
>


From jiangli.zhou at oracle.com  Wed Oct 10 09:41:19 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 10 Oct 2012 09:41:19 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074D35F.1080803@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074C9F3.3000702@oracle.com>
	<5074D35F.1080803@oracle.com>
Message-ID: <5075A52F.3040704@oracle.com>

Hi David,

On 10/09/2012 06:46 PM, David Holmes wrote:
> On 10/10/2012 11:05 AM, serguei.spitsyn at oracle.com wrote:
>> Hi Jiangli,
>>
>> I'm not very familiar with the pseudo strings, and so, just have a
>> question:
>>
>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>
>> 2927 entry = pool->resolved_string_at(i);
>> 2928 assert(java_lang_String::is_instance(entry) ||
>> 2929 pool->is_pseudo_string_at(i), "must be string");
>>
>> I have a little of doubt the above is correct.
>>
>> What value the "entry" will have in a case of pseudo string cp entry?
>> Just want to understand what constant pool reference will be reported.
>
> The pool stores strings and pseudo-strings in the same way. So 
> pool->resolved_string_at(i) and pool->pseudo_string_at(i, 
> cp_to_object_index(i)) return the same thing.
>
> So entry is either a real string or a pseudo-string - hence the assert 
> checks for either one.
>
> There were a number of ways this code could have been modified to 
> handle this, but augmenting the assert was simplest.

Exactly!

Thanks,
Jiangli

>
>> Do you see all related failing tests passed?
>>
>> Would something like the following be more accurate ?
>> entry = pool->is_pseudo_string_at(i) ?
>> pool->pseudo_string_at(i, cp_to_object_index(i)) :
>> pool->resolved_string_at(i);
>
> entry is the same no matter which path is taken.
>
>> assert(java_lang_String::is_instance(entry));
>
> That assert fails if entry was a pseudo-string.
>
> David
> -----
>
>> In this case, a reference from CP to string is reported regardless it is
>> pseudo string or not.
>>
>>
>> Thanks,
>> Serguei
>>
>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>> Please review following fix for 8000459:
>>>
>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>
>>> With JSR292, a constant pool String entry could be patched to a
>>> non-string oop. The assert in
>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to
>>> reflect that.
>>>
>>> Thanks,
>>>
>>> Jiangli
>>


From jiangli.zhou at oracle.com  Wed Oct 10 09:43:05 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 10 Oct 2012 09:43:05 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5074E07F.4030506@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074C9F3.3000702@oracle.com>
	<5074D35F.1080803@oracle.com> <5074E07F.4030506@oracle.com>
Message-ID: <5075A599.6040907@oracle.com>

Thanks, Serguei!

Jiangli

On 10/09/2012 07:42 PM, serguei.spitsyn at oracle.com wrote:
> Got it. Thanks, David.
> It means, pseudo string is not a java_lang_String.
>
> Jiangli,
> Thumbs up.
>
> Thanks,
> Serguei
>
>
> On 10/9/12 6:46 PM, David Holmes wrote:
>> On 10/10/2012 11:05 AM, serguei.spitsyn at oracle.com wrote:
>>> Hi Jiangli,
>>>
>>> I'm not very familiar with the pseudo strings, and so, just have a
>>> question:
>>>
>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>>
>>> 2927 entry = pool->resolved_string_at(i);
>>> 2928 assert(java_lang_String::is_instance(entry) ||
>>> 2929 pool->is_pseudo_string_at(i), "must be string");
>>>
>>> I have a little of doubt the above is correct.
>>>
>>> What value the "entry" will have in a case of pseudo string cp entry?
>>> Just want to understand what constant pool reference will be reported.
>>
>> The pool stores strings and pseudo-strings in the same way. So 
>> pool->resolved_string_at(i) and pool->pseudo_string_at(i, 
>> cp_to_object_index(i)) return the same thing.
>>
>> So entry is either a real string or a pseudo-string - hence the 
>> assert checks for either one.
>>
>> There were a number of ways this code could have been modified to 
>> handle this, but augmenting the assert was simplest.
>>
>>> Do you see all related failing tests passed?
>>>
>>> Would something like the following be more accurate ?
>>> entry = pool->is_pseudo_string_at(i) ?
>>> pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>> pool->resolved_string_at(i);
>>
>> entry is the same no matter which path is taken.
>>
>>> assert(java_lang_String::is_instance(entry));
>>
>> That assert fails if entry was a pseudo-string.
>>
>> David
>> -----
>>
>>> In this case, a reference from CP to string is reported regardless 
>>> it is
>>> pseudo string or not.
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>> Please review following fix for 8000459:
>>>>
>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>
>>>> With JSR292, a constant pool String entry could be patched to a
>>>> non-string oop. The assert in
>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to
>>>> reflect that.
>>>>
>>>> Thanks,
>>>>
>>>> Jiangli
>>>
>


From serguei.spitsyn at oracle.com  Wed Oct 10 09:44:21 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 10 Oct 2012 09:44:21 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5075A458.7040900@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074C9F3.3000702@oracle.com>
	<5075A458.7040900@oracle.com>
Message-ID: <5075A5E5.9030203@oracle.com>

Hi Jiangli,


On 10/10/12 9:37 AM, Jiangli Zhou wrote:
> Hi Serguei,
>
> Thanks for the review! Please see comments below.
>
> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Jiangli,
>>
>> I'm not very familiar with the pseudo strings, and so, just have a 
>> question:
>>
>> *src/share/vm/prims/jvmtiTagMap.cpp*
>> 2927             entry = pool->resolved_string_at(i);
>> 2928             assert(java_lang_String::is_instance(entry) ||
>> 2929                    pool->is_pseudo_string_at(i), "must be string");
>> I have a little of doubt the above is correct.
>>
>> What value the "entry" will have in a case of pseudo string cp entry?
>> Just want to understand what constant pool reference will be reported.
>> Do you see all related failing tests passed?
>>
>> Would something like the following be more accurate ?
>>    entry = pool->is_pseudo_string_at(i) ?
>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>                pool->resolved_string_at(i);
>> assert(java_lang_String::is_instance(entry));
>>
>> In this case, a reference from CP to string is reported regardless it 
>> is pseudo string or not.
>
> Those are very good questions. Here is an example of the specific case 
> with a generated JSR292 java.lang.invoke.LambdaForm$MH class. The 
> follow are two constant pool entries of the class. Entry 16 is a 
> "sun/misc/Unsafe" String, which could be patched using a 
> sun.misc.Unsafe klass oop.
>
>         ...
>         (0016) tag=Utf8 "sun/misc/Unsafe"
>         (0017) tag=Class "sun/misc/Unsafe"
>         ...
>
> I discussed with John Rose about different ways to fix the assertion 
> issue. The code you have above uses pseudo_string_at() to access the 
> 'entry', which is similar to one of the version we discussed. The 
> current change was chosen as it's the simplest solution.

I'm Ok with the simplest solution.

Thank you for the details!
-Serguei

>
> Thanks,
>
> Jiangli
>>
>>
>> Thanks,
>> Serguei
>>
>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>> Please review following fix for 8000459:
>>>
>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>
>>> With JSR292, a constant pool String entry could be patched to a 
>>> non-string oop. The assert in 
>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to 
>>> reflect that.
>>>
>>> Thanks,
>>>
>>> Jiangli
>>
>


From keith.mcguigan at oracle.com  Wed Oct 10 10:12:24 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 10 Oct 2012 13:12:24 -0400
Subject: Default methods for jdk8: request for code review
Message-ID: <5075AC78.3030702@oracle.com>

Hello,

I'd like any review of the code which implements default methods in the 
JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and 
tracked by CR 7200776.

The design and implementation is described in this short document:
http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt

And the code is here:
http://cr.openjdk.java.net/~kamg/default_methods/

Any review (even partial) would be appreciated.  Thanks!

--
- Keith

From coleen.phillimore at oracle.com  Wed Oct 10 10:50:40 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 10 Oct 2012 13:50:40 -0400
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5075A5E5.9030203@oracle.com>
References: <5074B2A7.6050503@oracle.com> <5074C9F3.3000702@oracle.com>
	<5075A458.7040900@oracle.com> <5075A5E5.9030203@oracle.com>
Message-ID: <5075B570.7040406@oracle.com>


This change looks good.  Thank you for fixing it.
Coleen

On 10/10/2012 12:44 PM, serguei.spitsyn at oracle.com wrote:
> Hi Jiangli,
>
>
> On 10/10/12 9:37 AM, Jiangli Zhou wrote:
>> Hi Serguei,
>>
>> Thanks for the review! Please see comments below.
>>
>> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Jiangli,
>>>
>>> I'm not very familiar with the pseudo strings, and so, just have a 
>>> question:
>>>
>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>> 2927             entry = pool->resolved_string_at(i);
>>> 2928             assert(java_lang_String::is_instance(entry) ||
>>> 2929                    pool->is_pseudo_string_at(i), "must be 
>>> string");
>>> I have a little of doubt the above is correct.
>>>
>>> What value the "entry" will have in a case of pseudo string cp entry?
>>> Just want to understand what constant pool reference will be reported.
>>> Do you see all related failing tests passed?
>>>
>>> Would something like the following be more accurate ?
>>>    entry = pool->is_pseudo_string_at(i) ?
>>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>>                pool->resolved_string_at(i);
>>> assert(java_lang_String::is_instance(entry));
>>>
>>> In this case, a reference from CP to string is reported regardless 
>>> it is pseudo string or not.
>>
>> Those are very good questions. Here is an example of the specific 
>> case with a generated JSR292 java.lang.invoke.LambdaForm$MH class. 
>> The follow are two constant pool entries of the class. Entry 16 is a 
>> "sun/misc/Unsafe" String, which could be patched using a 
>> sun.misc.Unsafe klass oop.
>>
>>         ...
>>         (0016) tag=Utf8 "sun/misc/Unsafe"
>>         (0017) tag=Class "sun/misc/Unsafe"
>>         ...
>>
>> I discussed with John Rose about different ways to fix the assertion 
>> issue. The code you have above uses pseudo_string_at() to access the 
>> 'entry', which is similar to one of the version we discussed. The 
>> current change was chosen as it's the simplest solution.
>
> I'm Ok with the simplest solution.
>
> Thank you for the details!
> -Serguei
>
>>
>> Thanks,
>>
>> Jiangli
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>> Please review following fix for 8000459:
>>>>
>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>
>>>> With JSR292, a constant pool String entry could be patched to a 
>>>> non-string oop. The assert in 
>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to 
>>>> reflect that.
>>>>
>>>> Thanks,
>>>>
>>>> Jiangli
>>>
>>
>

From jiangli.zhou at oracle.com  Wed Oct 10 10:53:51 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 10 Oct 2012 10:53:51 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5075B570.7040406@oracle.com>
References: <5074B2A7.6050503@oracle.com>
	<5074C9F3.3000702@oracle.com>	<5075A458.7040900@oracle.com>
	<5075A5E5.9030203@oracle.com> <5075B570.7040406@oracle.com>
Message-ID: <5075B62F.6090007@oracle.com>

Hi Coleen,

Thanks!

Jiangli

On 10/10/2012 10:50 AM, Coleen Phillimore wrote:
>
> This change looks good.  Thank you for fixing it.
> Coleen
>
> On 10/10/2012 12:44 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Jiangli,
>>
>>
>> On 10/10/12 9:37 AM, Jiangli Zhou wrote:
>>> Hi Serguei,
>>>
>>> Thanks for the review! Please see comments below.
>>>
>>> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Jiangli,
>>>>
>>>> I'm not very familiar with the pseudo strings, and so, just have a 
>>>> question:
>>>>
>>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>>> 2927             entry = pool->resolved_string_at(i);
>>>> 2928             assert(java_lang_String::is_instance(entry) ||
>>>> 2929                    pool->is_pseudo_string_at(i), "must be 
>>>> string");
>>>> I have a little of doubt the above is correct.
>>>>
>>>> What value the "entry" will have in a case of pseudo string cp entry?
>>>> Just want to understand what constant pool reference will be reported.
>>>> Do you see all related failing tests passed?
>>>>
>>>> Would something like the following be more accurate ?
>>>>    entry = pool->is_pseudo_string_at(i) ?
>>>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>>>                pool->resolved_string_at(i);
>>>> assert(java_lang_String::is_instance(entry));
>>>>
>>>> In this case, a reference from CP to string is reported regardless 
>>>> it is pseudo string or not.
>>>
>>> Those are very good questions. Here is an example of the specific 
>>> case with a generated JSR292 java.lang.invoke.LambdaForm$MH class. 
>>> The follow are two constant pool entries of the class. Entry 16 is a 
>>> "sun/misc/Unsafe" String, which could be patched using a 
>>> sun.misc.Unsafe klass oop.
>>>
>>>         ...
>>>         (0016) tag=Utf8 "sun/misc/Unsafe"
>>>         (0017) tag=Class "sun/misc/Unsafe"
>>>         ...
>>>
>>> I discussed with John Rose about different ways to fix the assertion 
>>> issue. The code you have above uses pseudo_string_at() to access the 
>>> 'entry', which is similar to one of the version we discussed. The 
>>> current change was chosen as it's the simplest solution.
>>
>> I'm Ok with the simplest solution.
>>
>> Thank you for the details!
>> -Serguei
>>
>>>
>>> Thanks,
>>>
>>> Jiangli
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>>> Please review following fix for 8000459:
>>>>>
>>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>>
>>>>> With JSR292, a constant pool String entry could be patched to a 
>>>>> non-string oop. The assert in 
>>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to 
>>>>> reflect that.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jiangli
>>>>
>>>
>>


From nils.loodin at oracle.com  Wed Oct 10 13:01:35 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Wed, 10 Oct 2012 22:01:35 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without the VM
	dying.
Message-ID: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>

Hi all!

When looking to implement a feature where I wanted to do some allocations without the vm calling vm_exit_no_memory() when not able to allocate, I discovered this wasn't possible with ResourceObj-type obects. (It was however implemented in CHeapObj-type objects.

Here's a patch to implement that.

Now we can use (for instance) jcmd on a running production vm without fear that we will bring the vm down if the jcmd commands does allocations.
(The commands themselves have to be implemented with this in mind though.)

Webrev here:
http://cr.openjdk.java.net/~nloodin/8000617/webrev.01/

Regards,
Nils Loodin

From vitalyd at gmail.com  Wed Oct 10 13:29:47 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 10 Oct 2012 16:29:47 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
Message-ID: <CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>

Hi Nils,

In thread.cpp, line 1614 - what's its purpose? Some leftover code?

In allocation.cpp, "dothrow" constant is assigned std::nothrow_t but isn't
nothrow_t for *not* throwing? This constant is then used to actually signal
oom in one of the methods - seems odd.

Also, in ResourceObject::operator new() there's an assertion that nothrow_t
== std::nothrow - what's the purpose? Why would someone use this overload
if they're not looking to skip bad_alloc? What sort of error are you
thinking of here?

Finally, I think the idiomatic way to do this type of stuff is to have a
separate overload of the alloc function that accepts nothrow_t whereas you
seem to have functions that take nothrow_t as a parameter, but then you
check if its the "dothrow" constant inside to see if oom should be
reported.  It seems cleaner to have overloads where the one taking
nothrow_t automatically means don't throw?

Thanks

Sent from my phone
On Oct 10, 2012 4:02 PM, "Nils Loodin" <nils.loodin at oracle.com> wrote:

> Hi all!
>
> When looking to implement a feature where I wanted to do some allocations
> without the vm calling vm_exit_no_memory() when not able to allocate, I
> discovered this wasn't possible with ResourceObj-type obects. (It was
> however implemented in CHeapObj-type objects.
>
> Here's a patch to implement that.
>
> Now we can use (for instance) jcmd on a running production vm without fear
> that we will bring the vm down if the jcmd commands does allocations.
> (The commands themselves have to be implemented with this in mind though.)
>
> Webrev here:
> http://cr.openjdk.java.net/~nloodin/8000617/webrev.01/
>
> Regards,
> Nils Loodin
>

From yumin.qi at oracle.com  Wed Oct 10 13:33:11 2012
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 10 Oct 2012 13:33:11 -0700
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
Message-ID: <5075DB87.3060902@oracle.com>

Hi, Nils

   As I know we did not use 'std' in hotspot code.

Thanks
Yumin


On 10/10/2012 1:01 PM, Nils Loodin wrote:
> Hi all!
>
> When looking to implement a feature where I wanted to do some 
> allocations without the vm calling vm_exit_no_memory() when not able 
> to allocate, I discovered this wasn't possible with ResourceObj-type 
> obects. (It was however implemented in CHeapObj-type objects.
>
> Here's a patch to implement that.
>
> Now we can use (for instance) jcmd on a running production vm without 
> fear that we will bring the vm down if the jcmd commands does allocations.
> (The commands themselves have to be implemented with this in mind though.)
>
> Webrev here:
> http://cr.openjdk.java.net/~nloodin/8000617/webrev.01/ 
> <http://cr.openjdk.java.net/%7Enloodin/8000617/webrev.01/>
>
> Regards,
> Nils Loodin

From keith.mcguigan at oracle.com  Wed Oct 10 13:39:50 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 10 Oct 2012 16:39:50 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
Message-ID: <5075DD16.8070602@oracle.com>



On 10/10/2012 4:29 PM, Vitaly Davidovich wrote:
> Hi Nils,
>
> In thread.cpp, line 1614 - what's its purpose? Some leftover code?
>
> In allocation.cpp, "dothrow" constant is assigned std::nothrow_t but isn't
> nothrow_t for *not* throwing? This constant is then used to actually signal
> oom in one of the methods - seems odd.
>
> Also, in ResourceObject::operator new() there's an assertion that nothrow_t
> == std::nothrow - what's the purpose? Why would someone use this overload
> if they're not looking to skip bad_alloc? What sort of error are you
> thinking of here?
>
> Finally, I think the idiomatic way to do this type of stuff is to have a
> separate overload of the alloc function that accepts nothrow_t whereas you
> seem to have functions that take nothrow_t as a parameter, but then you
> check if its the "dothrow" constant inside to see if oom should be
> reported.  It seems cleaner to have overloads where the one taking
> nothrow_t automatically means don't throw?

The problem with doing it that way is that it's harder to share code in 
the implementation of the allocation routines.  Either all of the 
routines (all the way down) need to be overloaded (and duplicated), or 
you need to both the overloads to call into a common subroutine which 
takes some parameter which indicates the throw mode.  It could be a 
'bool', but why not just use a std::nothrow_t instead?  It's much more 
descriptive at the callsite for what is actually going on, rather than a 
naked 'true' or 'false' which requires one to check the declaration to 
see the purpose.

That's essentially what this code is doing:  for the parts that are 
common, the nothrow/dothrow values are used as the discriminator.

(Oh and I give this a thumbs-up, Nils, once you get rid of that leftover 
line in thread.cpp).

--
- Keith

From vitalyd at gmail.com  Wed Oct 10 13:46:58 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 10 Oct 2012 16:46:58 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5075DD16.8070602@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
Message-ID: <CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>

Yeah, I figured it was done this way to save on code, it just doesn't look
typical/idiomatic I think and hence requires the "dothrow" discriminator;
dothrow = nothrow_t looks odd as well.

Instead of bool true/false, could use an enum to make it more readable.

Cheers guys

Sent from my phone
On Oct 10, 2012 4:41 PM, "Keith McGuigan" <keith.mcguigan at oracle.com> wrote:

>
>
> On 10/10/2012 4:29 PM, Vitaly Davidovich wrote:
>
>> Hi Nils,
>>
>> In thread.cpp, line 1614 - what's its purpose? Some leftover code?
>>
>> In allocation.cpp, "dothrow" constant is assigned std::nothrow_t but isn't
>> nothrow_t for *not* throwing? This constant is then used to actually
>> signal
>> oom in one of the methods - seems odd.
>>
>> Also, in ResourceObject::operator new() there's an assertion that
>> nothrow_t
>> == std::nothrow - what's the purpose? Why would someone use this overload
>> if they're not looking to skip bad_alloc? What sort of error are you
>> thinking of here?
>>
>> Finally, I think the idiomatic way to do this type of stuff is to have a
>> separate overload of the alloc function that accepts nothrow_t whereas you
>> seem to have functions that take nothrow_t as a parameter, but then you
>> check if its the "dothrow" constant inside to see if oom should be
>> reported.  It seems cleaner to have overloads where the one taking
>> nothrow_t automatically means don't throw?
>>
>
> The problem with doing it that way is that it's harder to share code in
> the implementation of the allocation routines.  Either all of the routines
> (all the way down) need to be overloaded (and duplicated), or you need to
> both the overloads to call into a common subroutine which takes some
> parameter which indicates the throw mode.  It could be a 'bool', but why
> not just use a std::nothrow_t instead?  It's much more descriptive at the
> callsite for what is actually going on, rather than a naked 'true' or
> 'false' which requires one to check the declaration to see the purpose.
>
> That's essentially what this code is doing:  for the parts that are
> common, the nothrow/dothrow values are used as the discriminator.
>
> (Oh and I give this a thumbs-up, Nils, once you get rid of that leftover
> line in thread.cpp).
>
> --
> - Keith
>

From john.r.rose at oracle.com  Wed Oct 10 13:53:45 2012
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 10 Oct 2012 13:53:45 -0700
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
Message-ID: <CD95EEF0-7FBD-40F2-99BF-9B449730FD93@oracle.com>

On Oct 10, 2012, at 1:46 PM, Vitaly Davidovich wrote:

> Instead of bool true/false, could use an enum to make it more readable.

It would also be more type-safe.

I don't like the reference external addressible object (&nothrow, &dothrow), despite the fact that apparently it is part of std.

The reason is that this forces allocation sites to materialize an additional externally linked constant.  Such constants are not free, especially in PIC code.  Many allocation sites (esp. resource-based ones) are performance-sensitive, and adding an extra reference to a global symbol is a backwards move.  (We added 'THREAD' arguments most places to fix a similar though worse problem getting Thread::current.)  I would prefer a boolean, enum, fake pointer, or struct, instead of a reference to a global.

? John

From keith.mcguigan at oracle.com  Wed Oct 10 13:53:48 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 10 Oct 2012 16:53:48 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
Message-ID: <5075E05C.90608@oracle.com>


Yeah, I hear what you're saying.  But 'nothrow_t' means "nothrow type". 
  Assigning a value of "dothrow" or "nothrow" to a variable of type 
"nothrow type" makes sense to me -- but I do have a weird viewpoint 
sometimes.

An enum would work fine too, as far as I'm concerned.  It seems wasteful 
to not reuse the perfectly fine type and value we already have in 
nothrow_t/nothrow, but hey, electrons are cheap...

--
- Keith

On 10/10/2012 4:46 PM, Vitaly Davidovich wrote:
> Yeah, I figured it was done this way to save on code, it just doesn't
> look typical/idiomatic I think and hence requires the "dothrow"
> discriminator; dothrow = nothrow_t looks odd as well.
>
> Instead of bool true/false, could use an enum to make it more readable.
>
> Cheers guys
>
> Sent from my phone
>
> On Oct 10, 2012 4:41 PM, "Keith McGuigan" <keith.mcguigan at oracle.com
> <mailto:keith.mcguigan at oracle.com>> wrote:
>
>
>
>     On 10/10/2012 4:29 PM, Vitaly Davidovich wrote:
>
>         Hi Nils,
>
>         In thread.cpp, line 1614 - what's its purpose? Some leftover code?
>
>         In allocation.cpp, "dothrow" constant is assigned std::nothrow_t
>         but isn't
>         nothrow_t for *not* throwing? This constant is then used to
>         actually signal
>         oom in one of the methods - seems odd.
>
>         Also, in ResourceObject::operator new() there's an assertion
>         that nothrow_t
>         == std::nothrow - what's the purpose? Why would someone use this
>         overload
>         if they're not looking to skip bad_alloc? What sort of error are you
>         thinking of here?
>
>         Finally, I think the idiomatic way to do this type of stuff is
>         to have a
>         separate overload of the alloc function that accepts nothrow_t
>         whereas you
>         seem to have functions that take nothrow_t as a parameter, but
>         then you
>         check if its the "dothrow" constant inside to see if oom should be
>         reported.  It seems cleaner to have overloads where the one taking
>         nothrow_t automatically means don't throw?
>
>
>     The problem with doing it that way is that it's harder to share code
>     in the implementation of the allocation routines.  Either all of the
>     routines (all the way down) need to be overloaded (and duplicated),
>     or you need to both the overloads to call into a common subroutine
>     which takes some parameter which indicates the throw mode.  It could
>     be a 'bool', but why not just use a std::nothrow_t instead?  It's
>     much more descriptive at the callsite for what is actually going on,
>     rather than a naked 'true' or 'false' which requires one to check
>     the declaration to see the purpose.
>
>     That's essentially what this code is doing:  for the parts that are
>     common, the nothrow/dothrow values are used as the discriminator.
>
>     (Oh and I give this a thumbs-up, Nils, once you get rid of that
>     leftover line in thread.cpp).
>
>     --
>     - Keith
>

From vitalyd at gmail.com  Wed Oct 10 14:10:35 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 10 Oct 2012 17:10:35 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5075E05C.90608@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
Message-ID: <CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>

The reason it looks strange to me (and of course, it could just be me) is
because nothrow_t is, in typical c++ code, always passed to the
non-throwing operator new; I've never seen it be used as a discriminator
*to* throw.  Again, just my 2 pennies though. :)

John, I think your concerns would be ameliorated if these were separate
overloads, right?

Sent from my phone
On Oct 10, 2012 4:54 PM, "Keith McGuigan" <keith.mcguigan at oracle.com> wrote:

>
> Yeah, I hear what you're saying.  But 'nothrow_t' means "nothrow type".
>  Assigning a value of "dothrow" or "nothrow" to a variable of type "nothrow
> type" makes sense to me -- but I do have a weird viewpoint sometimes.
>
> An enum would work fine too, as far as I'm concerned.  It seems wasteful
> to not reuse the perfectly fine type and value we already have in
> nothrow_t/nothrow, but hey, electrons are cheap...
>
> --
> - Keith
>
> On 10/10/2012 4:46 PM, Vitaly Davidovich wrote:
>
>> Yeah, I figured it was done this way to save on code, it just doesn't
>> look typical/idiomatic I think and hence requires the "dothrow"
>> discriminator; dothrow = nothrow_t looks odd as well.
>>
>> Instead of bool true/false, could use an enum to make it more readable.
>>
>> Cheers guys
>>
>> Sent from my phone
>>
>> On Oct 10, 2012 4:41 PM, "Keith McGuigan" <keith.mcguigan at oracle.com
>> <mailto:keith.mcguigan at oracle.**com <keith.mcguigan at oracle.com>>> wrote:
>>
>>
>>
>>     On 10/10/2012 4:29 PM, Vitaly Davidovich wrote:
>>
>>         Hi Nils,
>>
>>         In thread.cpp, line 1614 - what's its purpose? Some leftover code?
>>
>>         In allocation.cpp, "dothrow" constant is assigned std::nothrow_t
>>         but isn't
>>         nothrow_t for *not* throwing? This constant is then used to
>>         actually signal
>>         oom in one of the methods - seems odd.
>>
>>         Also, in ResourceObject::operator new() there's an assertion
>>         that nothrow_t
>>         == std::nothrow - what's the purpose? Why would someone use this
>>         overload
>>         if they're not looking to skip bad_alloc? What sort of error are
>> you
>>         thinking of here?
>>
>>         Finally, I think the idiomatic way to do this type of stuff is
>>         to have a
>>         separate overload of the alloc function that accepts nothrow_t
>>         whereas you
>>         seem to have functions that take nothrow_t as a parameter, but
>>         then you
>>         check if its the "dothrow" constant inside to see if oom should be
>>         reported.  It seems cleaner to have overloads where the one taking
>>         nothrow_t automatically means don't throw?
>>
>>
>>     The problem with doing it that way is that it's harder to share code
>>     in the implementation of the allocation routines.  Either all of the
>>     routines (all the way down) need to be overloaded (and duplicated),
>>     or you need to both the overloads to call into a common subroutine
>>     which takes some parameter which indicates the throw mode.  It could
>>     be a 'bool', but why not just use a std::nothrow_t instead?  It's
>>     much more descriptive at the callsite for what is actually going on,
>>     rather than a naked 'true' or 'false' which requires one to check
>>     the declaration to see the purpose.
>>
>>     That's essentially what this code is doing:  for the parts that are
>>     common, the nothrow/dothrow values are used as the discriminator.
>>
>>     (Oh and I give this a thumbs-up, Nils, once you get rid of that
>>     leftover line in thread.cpp).
>>
>>     --
>>     - Keith
>>
>>

From nils.loodin at oracle.com  Wed Oct 10 14:14:03 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Wed, 10 Oct 2012 23:14:03 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5075DB87.3060902@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<5075DB87.3060902@oracle.com>
Message-ID: <FAED1DC5-B7B7-4B54-869B-C0D9DAAACDF9@oracle.com>


On Oct 10, 2012, at 22:33 , Yumin Qi wrote:

> Hi, Nils
> 
>   As I know we did not use 'std' in hotspot code.

Hey Yumin! This isn't true, NMT code is already using std::nothrow. 
You can see it in memtracker.cpp, and also Thread already accepted std::nothrow, even if it wasn't set as const, so it couldn't really be used..

Regards,
Nils Loodin

> 
> Thanks
> Yumin
> 
> 
> On 10/10/2012 1:01 PM, Nils Loodin wrote:
>> 
>> Hi all!
>> 
>> When looking to implement a feature where I wanted to do some allocations without the vm calling vm_exit_no_memory() when not able to allocate, I discovered this wasn't possible with ResourceObj-type obects. (It was however implemented in CHeapObj-type objects.
>> 
>> Here's a patch to implement that.
>> 
>> Now we can use (for instance) jcmd on a running production vm without fear that we will bring the vm down if the jcmd commands does allocations.
>> (The commands themselves have to be implemented with this in mind though.)
>> 
>> Webrev here:
>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.01/
>> 
>> Regards,
>> Nils Loodin


From john.r.rose at oracle.com  Wed Oct 10 15:27:35 2012
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 10 Oct 2012 15:27:35 -0700
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
Message-ID: <FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>

On Oct 10, 2012, at 2:10 PM, Vitaly Davidovich wrote:

> John, I think your concerns would be ameliorated if these were separate
> overloads, right?

Yes.  Then the nothrow type is a singleton, whose value is never used (only noted to be present).  I'm kind of surprised that it's a global constant; there was a time when new (nothrow_t()) would have been the prescribed idiom, and that is safer.  But I am quite happily out of the loop on the latest C++ idioms.

Anyway, using "std" set off a small alarm bell for me.  (Keith, you know I'm a retro-C++ kind of guy.  HotSpot has always, and wisely, limited its dependencies on advanced C++ features.)

Seeing the reference comparison "&nothrow_arg == &really_throw_magic_value" set off big alarm bells.  That's what compiles to dirty machine code.  It also relies on parts of C++ that have been poorly specified in the past, i.e., the uniqueness of addressable constants.  All you need is a C++ compiler on some one-off platform to cleverly emit multiple local versions of nothrow and you are dead.

I would prefer to see both things go away, but certainly the latter.

Anything imported from the C++ exceptions world is a *bug* in our source base, not a new cool way of doing things.  We compile with -noex to simplify our ABI entanglements.

I propose that we treat new uses of std::nothrow (in NMT and wherever) as a bug.  Certainly it is not an "all clear" signal to double down on C++ exceptions of any sort.  (Not that anybody is going there yet, but there may be a slippery slope.)

? John

From jiangli.zhou at oracle.com  Wed Oct 10 15:43:27 2012
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Wed, 10 Oct 2012 22:43:27 +0000
Subject: hg: hsx/hsx24/hotspot: 8000459:
	assert(java_lang_String::is_instance(entry)) failure with
	various mlvm tests.
Message-ID: <20121010224338.25DDE472A1@hg.openjdk.java.net>

Changeset: 69e0b33357cc
Author:    jiangli
Date:      2012-10-10 15:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/69e0b33357cc

8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests.
Summary: The assert in VM_HeapWalkOperation::iterate_over_class() needs to be augmented for pseudo-string.
Reviewed-by: jrose, dholmes, sspitsyn, coleenp

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


From keith.mcguigan at oracle.com  Wed Oct 10 16:40:32 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 10 Oct 2012 19:40:32 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
Message-ID: <50760770.4030403@oracle.com>


Personally, I don't have strong feelings on how this is implemented, 
other than it should be done in a way that's maintainable going forward 
and easily understandable by future generations of hotspot developers. 
With this in mind, the only potential solution that I don't like is 
using a boolean with naked true/false values as discriminators.

Using some sort of "failure mode" parameter is the natural way to do 
this, whether it be enums, std::nothrow_t, or whatever.  Since 
std::nothrow_t already has a type and one value, and is already present 
in the few places we're interested in, it seemed easy to simple just add 
a new value to use.  However if this ends up being confusing because 
this is not the normal use of std::notype_t, then fine, we can do 
something else.

--
- Keith

From keith.mcguigan at oracle.com  Wed Oct 10 16:43:45 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 10 Oct 2012 19:43:45 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <CD95EEF0-7FBD-40F2-99BF-9B449730FD93@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<CD95EEF0-7FBD-40F2-99BF-9B449730FD93@oracle.com>
Message-ID: <50760831.8070508@oracle.com>



On 10/10/2012 4:53 PM, John Rose wrote:
> On Oct 10, 2012, at 1:46 PM, Vitaly Davidovich wrote:
>
>> Instead of bool true/false, could use an enum to make it more readable.
>
> It would also be more type-safe.
>
> I don't like the reference external addressible object (&nothrow,
> &dothrow), despite the fact that apparently it is part of std.
>
> The reason is that this forces allocation sites to materialize an
> additional externally linked constant.  Such constants are not free,
> especially in PIC code.  Many allocation sites (esp. resource-based
> ones) are performance-sensitive, and adding an extra reference to a
> global symbol is a backwards move.  (We added 'THREAD' arguments most
> places to fix a similar though worse problem getting Thread::current.)
>   I would prefer a boolean, enum, fake pointer, or struct, instead of a
> reference to a global.

The reference to the global would only be used in the exceeding rare 
case where memory allocation failed.   In fact, until now this only 
happened right before a VM abort.  We wouldn't be materializing a global 
reference at each allocation, for instance.

But I'm not a big fan of using a global either.  I was hoping there was 
some way to create a std::nothrow_t instance that would always be '!=' 
to std::nothrow.

--
- Keith

From christian.thalinger at oracle.com  Wed Oct 10 16:52:08 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 10 Oct 2012 16:52:08 -0700
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <C37DDD40-9FB4-48CC-AB4F-910B39428EF3@oracle.com>

Vote: yes

On Oct 9, 2012, at 7:12 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX Committer.
> 
> Vladimir is a member of the Hotspot Compiler group. Prior to joining Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 changesets to
> HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
> 
> Votes are due by Oct 23, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Vladimir Kozlov
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From vitalyd at gmail.com  Wed Oct 10 16:59:40 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 10 Oct 2012 19:59:40 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <5075AC78.3030702@oracle.com>
References: <5075AC78.3030702@oracle.com>
Message-ID: <CAHjP37FKdNq5FCL=uLzC3HUSYcVN0HSK53Hf=sZk6Uy6B7SQgw@mail.gmail.com>

Hi Keith,

In ResourceHashtable, how did you settle on size 1019? I see it's a prime
so presumably you're worried about collisions? I'd think a power of 2 would
give you some speed up as you can avoid the relatively expensive mod
operation, but just curious what your thinking is here.

Nice job on the "short" :) writeup by the way.

Thanks

Sent from my phone
On Oct 10, 2012 1:12 PM, "Keith McGuigan" <keith.mcguigan at oracle.com> wrote:

> Hello,
>
> I'd like any review of the code which implements default methods in the
> JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and
> tracked by CR 7200776.
>
> The design and implementation is described in this short document:
> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>
> And the code is here:
> http://cr.openjdk.java.net/~kamg/default_methods/
>
> Any review (even partial) would be appreciated.  Thanks!
>
> --
> - Keith
>
>

From keith.mcguigan at oracle.com  Wed Oct 10 17:08:48 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Wed, 10 Oct 2012 20:08:48 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <CAHjP37FKdNq5FCL=uLzC3HUSYcVN0HSK53Hf=sZk6Uy6B7SQgw@mail.gmail.com>
References: <5075AC78.3030702@oracle.com>
	<CAHjP37FKdNq5FCL=uLzC3HUSYcVN0HSK53Hf=sZk6Uy6B7SQgw@mail.gmail.com>
Message-ID: <50760E10.8000108@oracle.com>


You know I think I just picked it randomly as a prime that was close to 
1024.  I suppose by that criteria 1021 would have worked too.

Either of those are probably overkill, though.  And you're right that 
using a prime isn't necessary.  Maybe I should change that to 256 or 
something else a little more memory-usage-friendly.

Thanks!

--
- Keith

On 10/10/2012 7:59 PM, Vitaly Davidovich wrote:
> Hi Keith,
>
> In ResourceHashtable, how did you settle on size 1019? I see it's a
> prime so presumably you're worried about collisions? I'd think a power
> of 2 would give you some speed up as you can avoid the relatively
> expensive mod operation, but just curious what your thinking is here.
>
> Nice job on the "short" :) writeup by the way.
>
> Thanks
>
> Sent from my phone
>
> On Oct 10, 2012 1:12 PM, "Keith McGuigan" <keith.mcguigan at oracle.com
> <mailto:keith.mcguigan at oracle.com>> wrote:
>
>     Hello,
>
>     I'd like any review of the code which implements default methods in the
>     JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and
>     tracked by CR 7200776.
>
>     The design and implementation is described in this short document:
>     http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>
>     And the code is here:
>     http://cr.openjdk.java.net/~kamg/default_methods/
>
>     Any review (even partial) would be appreciated.  Thanks!
>
>     --
>     - Keith
>

From coleen.phillimore at oracle.com  Wed Oct 10 19:50:16 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 11 Oct 2012 02:50:16 +0000
Subject: hg: hsx/hotspot-main/hotspot: 12 new changesets
Message-ID: <20121011025042.15277472AB@hg.openjdk.java.net>

Changeset: d8ce2825b193
Author:    coleenp
Date:      2012-09-29 06:40 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d8ce2825b193

8000213: NPG: Should have renamed arrayKlass and typeArrayKlass
Summary: Capitalize these metadata types (and objArrayKlass)
Reviewed-by: stefank, twisti, kvn

! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciArrayKlass.cpp
! src/share/vm/ci/ciArrayKlass.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciKlass.hpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciObjArrayKlass.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciTypeArrayKlass.cpp
! src/share/vm/ci/ciTypeArrayKlass.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/memory/specialized_oop_closures.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/oops/objArrayKlass.inline.hpp
! src/share/vm/oops/objArrayOop.cpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/oops/oop.pcgc.inline.hpp
! src/share/vm/oops/oop.psgc.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.hpp
! src/share/vm/oops/typeArrayOop.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/threadService.cpp
! src/share/vm/shark/sharkRuntime.cpp

Changeset: fab6fbf427d2
Author:    kevinw
Date:      2012-09-30 23:24 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fab6fbf427d2

7200145: runtime/7196045/Test7196045.java fails with No class provided for `main'
Reviewed-by: dholmes, dsamersoff

! test/runtime/7196045/Test7196045.java

Changeset: ba8fd2fe198b
Author:    coleenp
Date:      2012-10-04 08:38 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ba8fd2fe198b

7198519: Broken build, hotspot-rt win USE_PRECOMPILED_HEADER=0
Summary: Uncommented out include for sys/stat.h and deleted include statements that were commented out.
Reviewed-by: coleenp, acorn, dholmes
Contributed-by: harold.seigel at oracle.com

! src/os/windows/vm/jvm_windows.h

Changeset: bacdc1d5c21c
Author:    coleenp
Date:      2012-10-04 08:43 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bacdc1d5c21c

6884973: java -XX:Atomics=2 crashes
Summary: Remove buggy experimental option
Reviewed-by: acorn, coleenp
Contributed-by: harold.seigel at oracle.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 48087f745a86
Author:    dholmes
Date:      2012-10-04 19:52 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/48087f745a86

7199186: runtime/7194254/Test7194254.java fails - wrong test name on @run
Reviewed-by: kvn, twisti

! test/runtime/7194254/Test7194254.java

Changeset: f2eb2d4488db
Author:    dholmes
Date:      2012-10-04 20:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f2eb2d4488db

Merge


Changeset: 75982791ddb6
Author:    coleenp
Date:      2012-10-08 09:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/75982791ddb6

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: 7a40901e0d5c
Author:    minqi
Date:      2012-10-08 16:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7a40901e0d5c

8000332: SA ClassDump throws exception after permgen removal
Summary: In ClassWrite.writeFields(), fields count was mistakenly set to fields length which overflow the array index. Also removed a file which is leftover from 6879063 changeset.
Reviewed-by: coleenp, sspitsyn
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/native/sadis.c

Changeset: 0e8ca886e4e1
Author:    minqi
Date:      2012-10-08 16:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0e8ca886e4e1

Merge


Changeset: 6e5a59a8e4a7
Author:    rbackman
Date:      2012-10-09 07:41 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6e5a59a8e4a7

Merge

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 26351ce8c4b0
Author:    coleenp
Date:      2012-10-09 02:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/26351ce8c4b0

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

Changeset: b9a9ed0f8eeb
Author:    mikael
Date:      2012-10-09 10:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b9a9ed0f8eeb

7197424: update copyright year to match last edit in jdk8 hotspot repository
Summary: Update copyright year to 2012 for relevant files
Reviewed-by: dholmes, coleenp

! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java
! agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java
! make/bsd/Makefile
! make/bsd/makefiles/adlc.make
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/dtrace.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/jvmg.make
! make/bsd/makefiles/launcher.make
! make/bsd/makefiles/product.make
! make/bsd/makefiles/rules.make
! make/bsd/makefiles/sparcWorks.make
! make/bsd/makefiles/top.make
! make/linux/makefiles/launcher.make
! make/linux/makefiles/ppc.make
! make/linux/makefiles/product.make
! make/linux/makefiles/rules.make
! make/linux/makefiles/sparcWorks.make
! make/linux/makefiles/top.make
! make/solaris/makefiles/adlc.make
! make/solaris/makefiles/gcc.make
! make/solaris/makefiles/jvmg.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/rules.make
! make/solaris/makefiles/top.make
! make/windows/build.bat
! make/windows/build_vm_def.sh
! make/windows/get_msc_ver.sh
! make/windows/makefiles/adlc.make
! make/windows/makefiles/launcher.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/rules.make
! make/windows/makefiles/sanity.make
! make/windows/makefiles/shared.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/common/Makefile
! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/x86/vm/c1_FrameMap_x86.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/cpu/x86/vm/templateTable_x86_32.hpp
! src/cpu/x86/vm/templateTable_x86_64.hpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/zero/vm/interpreterGenerator_zero.hpp
! src/cpu/zero/vm/methodHandles_zero.hpp
! src/os/bsd/vm/decoder_machO.cpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/decoder_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/posix/launcher/java_md.c
! src/os/posix/launcher/launcher.script
! src/os/posix/vm/os_posix.cpp
! src/os/posix/vm/os_posix.hpp
! src/os/solaris/dtrace/hs_private.d
! src/os/solaris/vm/attachListener_solaris.cpp
! src/os/solaris/vm/decoder_solaris.cpp
! src/os/solaris/vm/os_solaris.hpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/decoder_windows.hpp
! src/os/windows/vm/os_windows.hpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.hpp
! src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/solaris_x86_32.il
! src/os_cpu/solaris_x86/vm/solaris_x86_64.il
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/Util.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/register.hpp
! src/share/vm/c1/c1_CFGPrinter.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_LinearScan.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_ValueMap.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/c1/c1_ValueStack.cpp
! src/share/vm/c1/c1_ValueStack.hpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/ci/ciSymbol.cpp
! src/share/vm/ci/ciTypeFlow.hpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/javaAssertions.hpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/stubs.hpp
! src/share/vm/code/vmreg.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp
! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp
! src/share/vm/gc_implementation/g1/survRateGroup.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp
! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp
! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/shared/allocationStats.hpp
! src/share/vm/gc_implementation/shared/collectorCounters.cpp
! src/share/vm/gc_implementation/shared/collectorCounters.hpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp
! src/share/vm/gc_implementation/shared/gcStats.hpp
! src/share/vm/gc_implementation/shared/gcUtil.cpp
! src/share/vm/gc_implementation/shared/gcUtil.hpp
! src/share/vm/gc_implementation/shared/generationCounters.cpp
! src/share/vm/gc_implementation/shared/generationCounters.hpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/spaceCounters.cpp
! src/share/vm/gc_implementation/shared/spaceCounters.hpp
! src/share/vm/gc_implementation/shared/spaceDecorator.hpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/libadt/set.cpp
! src/share/vm/libadt/vectset.cpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/freeList.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/heap.hpp
! src/share/vm/memory/referencePolicy.hpp
! src/share/vm/memory/space.inline.hpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/divnode.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/prims/jniExport.hpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/prims/jvmtiExtensions.cpp
! src/share/vm/prims/jvmtiRawMonitor.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/prims/jvmtiUtil.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/dtraceJSDT.hpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/monitorChunk.cpp
! src/share/vm/runtime/monitorChunk.hpp
! src/share/vm/runtime/mutex.hpp
! src/share/vm/runtime/park.cpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/task.hpp
! src/share/vm/runtime/timer.cpp
! src/share/vm/runtime/vmThread.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/g1MemoryPool.cpp
! src/share/vm/services/g1MemoryPool.hpp
! src/share/vm/services/lowMemoryDetector.hpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/trace/tracing.hpp
! src/share/vm/utilities/array.cpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder_elf.cpp
! src/share/vm/utilities/elfFile.cpp
! src/share/vm/utilities/elfFile.hpp
! src/share/vm/utilities/elfStringTable.cpp
! src/share/vm/utilities/elfStringTable.hpp
! src/share/vm/utilities/elfSymbolTable.cpp
! src/share/vm/utilities/elfSymbolTable.hpp
! src/share/vm/utilities/globalDefinitions_visCPP.hpp
! src/share/vm/utilities/growableArray.cpp
! src/share/vm/utilities/histogram.cpp
! src/share/vm/utilities/histogram.hpp
! src/share/vm/utilities/intHisto.cpp
! src/share/vm/utilities/intHisto.hpp
! src/share/vm/utilities/preserveException.cpp
! src/share/vm/utilities/stack.hpp
! src/share/vm/utilities/stack.inline.hpp
! src/share/vm/utilities/taskqueue.hpp
! src/share/vm/utilities/vmError.hpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp
! test/compiler/6859338/Test6859338.java
! test/compiler/7116216/StackOverflow.java


From frederic.parain at oracle.com  Thu Oct 11 02:05:03 2012
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 11 Oct 2012 11:05:03 +0200
Subject: CFV: New HSX Committer: Vladimir Ivanov
In-Reply-To: <5074D97C.2000604@oracle.com>
References: <5074D97C.2000604@oracle.com>
Message-ID: <50768BBF.6060708@oracle.com>

Vote: yes

Fred

On 10/10/12 04:12 AM, Vladimir Kozlov wrote:
> I hereby nominate Vladimir Ivanov (OpenJDK user name: vlivanov) to HSX
> Committer.
>
> Vladimir is a member of the Hotspot Compiler group. Prior to joining
> Hotspot
> development, he worked in Hotspot SQE group. He contributed 8 changesets to
> HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vladimir.x.ivanov
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=vlivanov
>
> Votes are due by Oct 23, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this
> nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Vladimir Kozlov
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at Oracle.com


From Dmitry.Samersoff at oracle.com  Thu Oct 11 04:21:51 2012
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 11 Oct 2012 15:21:51 +0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <50760770.4030403@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com>
Message-ID: <5076ABCF.5020005@oracle.com>

Keith,

Personally, I would prefer explicit AllocWithoutThrow(...) function.

-Dmitry



On 2012-10-11 03:40, Keith McGuigan wrote:
> 
> Personally, I don't have strong feelings on how this is implemented,
> other than it should be done in a way that's maintainable going forward
> and easily understandable by future generations of hotspot developers.
> With this in mind, the only potential solution that I don't like is
> using a boolean with naked true/false values as discriminators.
> 
> Using some sort of "failure mode" parameter is the natural way to do
> this, whether it be enums, std::nothrow_t, or whatever.  Since
> std::nothrow_t already has a type and one value, and is already present
> in the few places we're interested in, it seemed easy to simple just add
> a new value to use.  However if this ends up being confusing because
> this is not the normal use of std::notype_t, then fine, we can do
> something else.
> 
> -- 
> - Keith


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

From vitalyd at gmail.com  Thu Oct 11 05:04:20 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 11 Oct 2012 08:04:20 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <50760E10.8000108@oracle.com>
References: <5075AC78.3030702@oracle.com>
	<CAHjP37FKdNq5FCL=uLzC3HUSYcVN0HSK53Hf=sZk6Uy6B7SQgw@mail.gmail.com>
	<50760E10.8000108@oracle.com>
Message-ID: <CAHjP37G7LFj5otmN08r0JV3wWN=DWSSE_uCGGW_109K8k7yHJg@mail.gmail.com>

Keith,

In defaultMethods.cpp, I think there are a few places missing a
ResourceMark, e.g. print_exception() but there are others.  If you search
for as_C_string() you'll find them.

In genericSignatures.cpp, DescriptorStream::parse_error() asserts that the
error is null - is that right?

Also, assert_char() - does the buffer need to be from the resource area?
I'd think a stack one would work here?

Sorry for the piecemeal comments - I'm looking at the code on my phone so
it's a bit slower :).

Thanks

Sent from my phone
On Oct 10, 2012 8:09 PM, "Keith McGuigan" <keith.mcguigan at oracle.com> wrote:

>
> You know I think I just picked it randomly as a prime that was close to
> 1024.  I suppose by that criteria 1021 would have worked too.
>
> Either of those are probably overkill, though.  And you're right that
> using a prime isn't necessary.  Maybe I should change that to 256 or
> something else a little more memory-usage-friendly.
>
> Thanks!
>
> --
> - Keith
>
> On 10/10/2012 7:59 PM, Vitaly Davidovich wrote:
>
>> Hi Keith,
>>
>> In ResourceHashtable, how did you settle on size 1019? I see it's a
>> prime so presumably you're worried about collisions? I'd think a power
>> of 2 would give you some speed up as you can avoid the relatively
>> expensive mod operation, but just curious what your thinking is here.
>>
>> Nice job on the "short" :) writeup by the way.
>>
>> Thanks
>>
>> Sent from my phone
>>
>> On Oct 10, 2012 1:12 PM, "Keith McGuigan" <keith.mcguigan at oracle.com
>> <mailto:keith.mcguigan at oracle.**com <keith.mcguigan at oracle.com>>> wrote:
>>
>>     Hello,
>>
>>     I'd like any review of the code which implements default methods in
>> the
>>     JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and
>>     tracked by CR 7200776.
>>
>>     The design and implementation is described in this short document:
>>     http://cr.openjdk.java.net/~**kamg/default_methods_in_**hotspot.txt<http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt>
>>
>>     And the code is here:
>>     http://cr.openjdk.java.net/~**kamg/default_methods/<http://cr.openjdk.java.net/~kamg/default_methods/>
>>
>>     Any review (even partial) would be appreciated.  Thanks!
>>
>>     --
>>     - Keith
>>
>>

From keith.mcguigan at oracle.com  Thu Oct 11 05:46:51 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Thu, 11 Oct 2012 08:46:51 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <CAHjP37G7LFj5otmN08r0JV3wWN=DWSSE_uCGGW_109K8k7yHJg@mail.gmail.com>
References: <5075AC78.3030702@oracle.com>
	<CAHjP37FKdNq5FCL=uLzC3HUSYcVN0HSK53Hf=sZk6Uy6B7SQgw@mail.gmail.com>
	<50760E10.8000108@oracle.com>
	<CAHjP37G7LFj5otmN08r0JV3wWN=DWSSE_uCGGW_109K8k7yHJg@mail.gmail.com>
Message-ID: <9D72A7B5-CC67-4043-8A79-C51138391E39@oracle.com>


On Oct 11, 2012, at 8:04 AM, Vitaly Davidovich wrote:

> Keith,
> 
> In defaultMethods.cpp, I think there are a few places missing a ResourceMark, e.g. print_exception() but there are others.  If you search for as_C_string() you'll find them.
> 
Because the only entrances to this code, (generate_default_methods() and find_super_default()) have a resource mark at the beginning, all of these tracing message are covered by a resource mark.  More marks in these print locations would use a little less incidental memory when tracing is enabled,  but I'm not too worried about that.

> In genericSignatures.cpp, DescriptorStream::parse_error() asserts that the error is null - is that right?
> 
No, that doesn't make any sense at all.  I can't even imagine what kind of situation would bring a nonsensical thing like that into light.  Removed!  (also I suppose I'll add a set_parse_error() method and add a message != NULL assert in there instead).
> Also, assert_char() - does the buffer need to be from the resource area? I'd think a stack one would work here?
> 
No, in this case I do need that buffer to be a resource array.  If it were on the stack it would be in 'asert_char()'s frame and would be deallocated as soon as that function returns.

> Sorry for the piecemeal comments - I'm looking at the code on my phone so it's a bit slower :).

No problem at all, keep them coming!  And thanks!

--
- Keith


From vitalyd at gmail.com  Thu Oct 11 05:52:44 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 11 Oct 2012 08:52:44 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <9D72A7B5-CC67-4043-8A79-C51138391E39@oracle.com>
References: <5075AC78.3030702@oracle.com>
	<CAHjP37FKdNq5FCL=uLzC3HUSYcVN0HSK53Hf=sZk6Uy6B7SQgw@mail.gmail.com>
	<50760E10.8000108@oracle.com>
	<CAHjP37G7LFj5otmN08r0JV3wWN=DWSSE_uCGGW_109K8k7yHJg@mail.gmail.com>
	<9D72A7B5-CC67-4043-8A79-C51138391E39@oracle.com>
Message-ID: <CAHjP37GY7h-MYcHjORPq8x80n5QVryUu+4ZNf6-v2tBquuVizw@mail.gmail.com>

Understood on resource marks - thanks.  Perhaps just a comment then saying
caller assumed to have set up a mark?

I completely missed the assignment of the buffer into the field - don't
know how.  Sorry for the noise on that one.

I'll keep looking as time permits :)

Thanks

Sent from my phone
On Oct 11, 2012 8:46 AM, "Keith McGuigan" <keith.mcguigan at oracle.com> wrote:

>
> On Oct 11, 2012, at 8:04 AM, Vitaly Davidovich wrote:
>
> Keith,
>
> In defaultMethods.cpp, I think there are a few places missing a
> ResourceMark, e.g. print_exception() but there are others.  If you search
> for as_C_string() you'll find them.
>
> Because the only entrances to this code, (generate_default_methods() and
> find_super_default()) have a resource mark at the beginning, all of these
> tracing message are covered by a resource mark.  More marks in these print
> locations would use a little less incidental memory when tracing is
> enabled,  but I'm not too worried about that.
>
> In genericSignatures.cpp, DescriptorStream::parse_error() asserts that the
> error is null - is that right?
>
> No, that doesn't make any sense at all.  I can't even imagine what kind of
> situation would bring a nonsensical thing like that into light.  Removed!
>  (also I suppose I'll add a set_parse_error() method and add a message !=
> NULL assert in there instead).
>
> Also, assert_char() - does the buffer need to be from the resource area?
> I'd think a stack one would work here?
>
> No, in this case I do need that buffer to be a resource array.  If it were
> on the stack it would be in 'asert_char()'s frame and would be deallocated
> as soon as that function returns.
>
> Sorry for the piecemeal comments - I'm looking at the code on my phone so
> it's a bit slower :).
>
>
> No problem at all, keep them coming!  And thanks!
>
> --
> - Keith
>
>

From nils.loodin at oracle.com  Thu Oct 11 05:55:30 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Thu, 11 Oct 2012 14:55:30 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5076ABCF.5020005@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
Message-ID: <5076C1C2.30408@oracle.com>

Hey guys.

Your comments on this issue are great! So here's another version that
uses an enum instead of std::nothrow_t trickery!

http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/

Regards,
Nils Loodin




On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
> Keith,
>
> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>
> -Dmitry
>
>
>
> On 2012-10-11 03:40, Keith McGuigan wrote:
>>
>> Personally, I don't have strong feelings on how this is implemented,
>> other than it should be done in a way that's maintainable going forward
>> and easily understandable by future generations of hotspot developers.
>> With this in mind, the only potential solution that I don't like is
>> using a boolean with naked true/false values as discriminators.
>>
>> Using some sort of "failure mode" parameter is the natural way to do
>> this, whether it be enums, std::nothrow_t, or whatever.  Since
>> std::nothrow_t already has a type and one value, and is already present
>> in the few places we're interested in, it seemed easy to simple just add
>> a new value to use.  However if this ends up being confusing because
>> this is not the normal use of std::notype_t, then fine, we can do
>> something else.
>>
>> --
>> - Keith
>
>


From rkennke at redhat.com  Thu Oct 11 07:55:09 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 11 Oct 2012 16:55:09 +0200
Subject: RFR: Make Zero build and run with JDK8
Message-ID: <1349967309.1682.12.camel@moonlight>

Hello,

In the recent weeks I worked on the Zero interpreter, to get it to build
and run with JDK8, and in particular with the latest changes that came
from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:

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

A few notes on the patch:
- Some makefile changes have been necessary to get it to build at all.
- A bunch of stub functions needed to be added to make the compiler
happy, they should not be called though.
- Most of the changes are related to JSR292 stuff, in particular the
added invokehandle handler, and the changes to invokedynamic resulting
from how the constant pool entry has changed (e.g. method is now in f1).
- A lot of code relating to JSR292 could be removed because most of the
logic has been moved to the (Java) lambda forms.
- A few native methods have been added (MH.invokeBasic(),
MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).

With those changes it's possible to build the Zero-JDK with itself, and
run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
TCK or such, this would have to wait until all this gets backported to
JDK7 anyway, and I wanted to get some feedback on the changes first.

So what do you think?

And what are the next steps to (hopefully) get those changes committed?
I guess I need a bug-ID and formal review ?

And in case this is not the correct mailing list, please fwd to and/or
CC the correct list.

Thanks and kind regards,
Roman



From jiangli.zhou at oracle.com  Thu Oct 11 08:59:06 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 11 Oct 2012 08:59:06 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5075B570.7040406@oracle.com>
References: <5074B2A7.6050503@oracle.com>
	<5074C9F3.3000702@oracle.com>	<5075A458.7040900@oracle.com>
	<5075A5E5.9030203@oracle.com> <5075B570.7040406@oracle.com>
Message-ID: <5076ECCA.2050005@oracle.com>

Hi Coleen,

Here is the webrev that removes the assert from the latest hsx25 
repository with PermGen removal. The assert doesn't add any real value. 
I also fixed a small typo.

   http://cr.openjdk.java.net/~jiangli/8000459/webrev.01/

The previous webrev was based on hsx24, which is pre-PerGen removal. I 
should have included that detail in the first review request.

Thanks,

Jiangli

On 10/10/2012 10:50 AM, Coleen Phillimore wrote:
>
> This change looks good.  Thank you for fixing it.
> Coleen
>
> On 10/10/2012 12:44 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Jiangli,
>>
>>
>> On 10/10/12 9:37 AM, Jiangli Zhou wrote:
>>> Hi Serguei,
>>>
>>> Thanks for the review! Please see comments below.
>>>
>>> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Jiangli,
>>>>
>>>> I'm not very familiar with the pseudo strings, and so, just have a 
>>>> question:
>>>>
>>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>>> 2927             entry = pool->resolved_string_at(i);
>>>> 2928             assert(java_lang_String::is_instance(entry) ||
>>>> 2929                    pool->is_pseudo_string_at(i), "must be 
>>>> string");
>>>> I have a little of doubt the above is correct.
>>>>
>>>> What value the "entry" will have in a case of pseudo string cp entry?
>>>> Just want to understand what constant pool reference will be reported.
>>>> Do you see all related failing tests passed?
>>>>
>>>> Would something like the following be more accurate ?
>>>>    entry = pool->is_pseudo_string_at(i) ?
>>>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>>>                pool->resolved_string_at(i);
>>>> assert(java_lang_String::is_instance(entry));
>>>>
>>>> In this case, a reference from CP to string is reported regardless 
>>>> it is pseudo string or not.
>>>
>>> Those are very good questions. Here is an example of the specific 
>>> case with a generated JSR292 java.lang.invoke.LambdaForm$MH class. 
>>> The follow are two constant pool entries of the class. Entry 16 is a 
>>> "sun/misc/Unsafe" String, which could be patched using a 
>>> sun.misc.Unsafe klass oop.
>>>
>>>         ...
>>>         (0016) tag=Utf8 "sun/misc/Unsafe"
>>>         (0017) tag=Class "sun/misc/Unsafe"
>>>         ...
>>>
>>> I discussed with John Rose about different ways to fix the assertion 
>>> issue. The code you have above uses pseudo_string_at() to access the 
>>> 'entry', which is similar to one of the version we discussed. The 
>>> current change was chosen as it's the simplest solution.
>>
>> I'm Ok with the simplest solution.
>>
>> Thank you for the details!
>> -Serguei
>>
>>>
>>> Thanks,
>>>
>>> Jiangli
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>>> Please review following fix for 8000459:
>>>>>
>>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>>
>>>>> With JSR292, a constant pool String entry could be patched to a 
>>>>> non-string oop. The assert in 
>>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted to 
>>>>> reflect that.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jiangli
>>>>
>>>
>>


From coleen.phillimore at oracle.com  Thu Oct 11 10:22:04 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 11 Oct 2012 13:22:04 -0400
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5076ECCA.2050005@oracle.com>
References: <5074B2A7.6050503@oracle.com>
	<5074C9F3.3000702@oracle.com>	<5075A458.7040900@oracle.com>
	<5075A5E5.9030203@oracle.com> <5075B570.7040406@oracle.com>
	<5076ECCA.2050005@oracle.com>
Message-ID: <5077003C.7070606@oracle.com>


Looks good to me.
Coleen

On 10/11/2012 11:59 AM, Jiangli Zhou wrote:
> Hi Coleen,
>
> Here is the webrev that removes the assert from the latest hsx25 
> repository with PermGen removal. The assert doesn't add any real 
> value. I also fixed a small typo.
>
>   http://cr.openjdk.java.net/~jiangli/8000459/webrev.01/
>
> The previous webrev was based on hsx24, which is pre-PerGen removal. I 
> should have included that detail in the first review request.
>
> Thanks,
>
> Jiangli
>
> On 10/10/2012 10:50 AM, Coleen Phillimore wrote:
>>
>> This change looks good.  Thank you for fixing it.
>> Coleen
>>
>> On 10/10/2012 12:44 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Jiangli,
>>>
>>>
>>> On 10/10/12 9:37 AM, Jiangli Zhou wrote:
>>>> Hi Serguei,
>>>>
>>>> Thanks for the review! Please see comments below.
>>>>
>>>> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Hi Jiangli,
>>>>>
>>>>> I'm not very familiar with the pseudo strings, and so, just have a 
>>>>> question:
>>>>>
>>>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>>>> 2927             entry = pool->resolved_string_at(i);
>>>>> 2928             assert(java_lang_String::is_instance(entry) ||
>>>>> 2929                    pool->is_pseudo_string_at(i), "must be 
>>>>> string");
>>>>> I have a little of doubt the above is correct.
>>>>>
>>>>> What value the "entry" will have in a case of pseudo string cp entry?
>>>>> Just want to understand what constant pool reference will be 
>>>>> reported.
>>>>> Do you see all related failing tests passed?
>>>>>
>>>>> Would something like the following be more accurate ?
>>>>>    entry = pool->is_pseudo_string_at(i) ?
>>>>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>>>>                pool->resolved_string_at(i);
>>>>> assert(java_lang_String::is_instance(entry));
>>>>>
>>>>> In this case, a reference from CP to string is reported regardless 
>>>>> it is pseudo string or not.
>>>>
>>>> Those are very good questions. Here is an example of the specific 
>>>> case with a generated JSR292 java.lang.invoke.LambdaForm$MH class. 
>>>> The follow are two constant pool entries of the class. Entry 16 is 
>>>> a "sun/misc/Unsafe" String, which could be patched using a 
>>>> sun.misc.Unsafe klass oop.
>>>>
>>>>         ...
>>>>         (0016) tag=Utf8 "sun/misc/Unsafe"
>>>>         (0017) tag=Class "sun/misc/Unsafe"
>>>>         ...
>>>>
>>>> I discussed with John Rose about different ways to fix the 
>>>> assertion issue. The code you have above uses pseudo_string_at() to 
>>>> access the 'entry', which is similar to one of the version we 
>>>> discussed. The current change was chosen as it's the simplest 
>>>> solution.
>>>
>>> I'm Ok with the simplest solution.
>>>
>>> Thank you for the details!
>>> -Serguei
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jiangli
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>>>> Please review following fix for 8000459:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>>>
>>>>>> With JSR292, a constant pool String entry could be patched to a 
>>>>>> non-string oop. The assert in 
>>>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted 
>>>>>> to reflect that.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jiangli
>>>>>
>>>>
>>>
>

From jiangli.zhou at oracle.com  Thu Oct 11 10:42:02 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 11 Oct 2012 10:42:02 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5077003C.7070606@oracle.com>
References: <5074B2A7.6050503@oracle.com>
	<5074C9F3.3000702@oracle.com>	<5075A458.7040900@oracle.com>
	<5075A5E5.9030203@oracle.com> <5075B570.7040406@oracle.com>
	<5076ECCA.2050005@oracle.com> <5077003C.7070606@oracle.com>
Message-ID: <507704EA.1080605@oracle.com>

Thanks again, Coleen!

Jiangli

On 10/11/2012 10:22 AM, Coleen Phillimore wrote:
>
> Looks good to me.
> Coleen
>
> On 10/11/2012 11:59 AM, Jiangli Zhou wrote:
>> Hi Coleen,
>>
>> Here is the webrev that removes the assert from the latest hsx25 
>> repository with PermGen removal. The assert doesn't add any real 
>> value. I also fixed a small typo.
>>
>>   http://cr.openjdk.java.net/~jiangli/8000459/webrev.01/
>>
>> The previous webrev was based on hsx24, which is pre-PerGen removal. 
>> I should have included that detail in the first review request.
>>
>> Thanks,
>>
>> Jiangli
>>
>> On 10/10/2012 10:50 AM, Coleen Phillimore wrote:
>>>
>>> This change looks good.  Thank you for fixing it.
>>> Coleen
>>>
>>> On 10/10/2012 12:44 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Jiangli,
>>>>
>>>>
>>>> On 10/10/12 9:37 AM, Jiangli Zhou wrote:
>>>>> Hi Serguei,
>>>>>
>>>>> Thanks for the review! Please see comments below.
>>>>>
>>>>> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Hi Jiangli,
>>>>>>
>>>>>> I'm not very familiar with the pseudo strings, and so, just have 
>>>>>> a question:
>>>>>>
>>>>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>>>>> 2927             entry = pool->resolved_string_at(i);
>>>>>> 2928             assert(java_lang_String::is_instance(entry) ||
>>>>>> 2929                    pool->is_pseudo_string_at(i), "must be 
>>>>>> string");
>>>>>> I have a little of doubt the above is correct.
>>>>>>
>>>>>> What value the "entry" will have in a case of pseudo string cp 
>>>>>> entry?
>>>>>> Just want to understand what constant pool reference will be 
>>>>>> reported.
>>>>>> Do you see all related failing tests passed?
>>>>>>
>>>>>> Would something like the following be more accurate ?
>>>>>>    entry = pool->is_pseudo_string_at(i) ?
>>>>>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>>>>>                pool->resolved_string_at(i);
>>>>>> assert(java_lang_String::is_instance(entry));
>>>>>>
>>>>>> In this case, a reference from CP to string is reported 
>>>>>> regardless it is pseudo string or not.
>>>>>
>>>>> Those are very good questions. Here is an example of the specific 
>>>>> case with a generated JSR292 java.lang.invoke.LambdaForm$MH class. 
>>>>> The follow are two constant pool entries of the class. Entry 16 is 
>>>>> a "sun/misc/Unsafe" String, which could be patched using a 
>>>>> sun.misc.Unsafe klass oop.
>>>>>
>>>>>         ...
>>>>>         (0016) tag=Utf8 "sun/misc/Unsafe"
>>>>>         (0017) tag=Class "sun/misc/Unsafe"
>>>>>         ...
>>>>>
>>>>> I discussed with John Rose about different ways to fix the 
>>>>> assertion issue. The code you have above uses pseudo_string_at() 
>>>>> to access the 'entry', which is similar to one of the version we 
>>>>> discussed. The current change was chosen as it's the simplest 
>>>>> solution.
>>>>
>>>> I'm Ok with the simplest solution.
>>>>
>>>> Thank you for the details!
>>>> -Serguei
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jiangli
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>>>>> Please review following fix for 8000459:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>>>>
>>>>>>> With JSR292, a constant pool String entry could be patched to a 
>>>>>>> non-string oop. The assert in 
>>>>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted 
>>>>>>> to reflect that.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jiangli
>>>>>>
>>>>>
>>>>
>>


From serguei.spitsyn at oracle.com  Thu Oct 11 10:46:50 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 11 Oct 2012 10:46:50 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5076ECCA.2050005@oracle.com>
References: <5074B2A7.6050503@oracle.com>
	<5074C9F3.3000702@oracle.com>	<5075A458.7040900@oracle.com>
	<5075A5E5.9030203@oracle.com> <5075B570.7040406@oracle.com>
	<5076ECCA.2050005@oracle.com>
Message-ID: <5077060A.6010809@oracle.com>

Looks good.

Thanks,
Serguei

On 10/11/12 8:59 AM, Jiangli Zhou wrote:
> Hi Coleen,
>
> Here is the webrev that removes the assert from the latest hsx25 
> repository with PermGen removal. The assert doesn't add any real 
> value. I also fixed a small typo.
>
>   http://cr.openjdk.java.net/~jiangli/8000459/webrev.01/
>
> The previous webrev was based on hsx24, which is pre-PerGen removal. I 
> should have included that detail in the first review request.
>
> Thanks,
>
> Jiangli
>
> On 10/10/2012 10:50 AM, Coleen Phillimore wrote:
>>
>> This change looks good.  Thank you for fixing it.
>> Coleen
>>
>> On 10/10/2012 12:44 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Jiangli,
>>>
>>>
>>> On 10/10/12 9:37 AM, Jiangli Zhou wrote:
>>>> Hi Serguei,
>>>>
>>>> Thanks for the review! Please see comments below.
>>>>
>>>> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Hi Jiangli,
>>>>>
>>>>> I'm not very familiar with the pseudo strings, and so, just have a 
>>>>> question:
>>>>>
>>>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>>>> 2927             entry = pool->resolved_string_at(i);
>>>>> 2928 assert(java_lang_String::is_instance(entry) ||
>>>>> 2929                    pool->is_pseudo_string_at(i), "must be 
>>>>> string");
>>>>> I have a little of doubt the above is correct.
>>>>>
>>>>> What value the "entry" will have in a case of pseudo string cp entry?
>>>>> Just want to understand what constant pool reference will be 
>>>>> reported.
>>>>> Do you see all related failing tests passed?
>>>>>
>>>>> Would something like the following be more accurate ?
>>>>>    entry = pool->is_pseudo_string_at(i) ?
>>>>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>>>>                pool->resolved_string_at(i);
>>>>> assert(java_lang_String::is_instance(entry));
>>>>>
>>>>> In this case, a reference from CP to string is reported regardless 
>>>>> it is pseudo string or not.
>>>>
>>>> Those are very good questions. Here is an example of the specific 
>>>> case with a generated JSR292 java.lang.invoke.LambdaForm$MH class. 
>>>> The follow are two constant pool entries of the class. Entry 16 is 
>>>> a "sun/misc/Unsafe" String, which could be patched using a 
>>>> sun.misc.Unsafe klass oop.
>>>>
>>>>         ...
>>>>         (0016) tag=Utf8 "sun/misc/Unsafe"
>>>>         (0017) tag=Class "sun/misc/Unsafe"
>>>>         ...
>>>>
>>>> I discussed with John Rose about different ways to fix the 
>>>> assertion issue. The code you have above uses pseudo_string_at() to 
>>>> access the 'entry', which is similar to one of the version we 
>>>> discussed. The current change was chosen as it's the simplest 
>>>> solution.
>>>
>>> I'm Ok with the simplest solution.
>>>
>>> Thank you for the details!
>>> -Serguei
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jiangli
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>>>> Please review following fix for 8000459:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>>>
>>>>>> With JSR292, a constant pool String entry could be patched to a 
>>>>>> non-string oop. The assert in 
>>>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted 
>>>>>> to reflect that.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jiangli
>>>>>
>>>>
>>>
>


From jiangli.zhou at oracle.com  Thu Oct 11 10:47:20 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 11 Oct 2012 10:47:20 -0700
Subject: Review request: 8000459:
	assert(java_lang_String::is_instance(entry))
	failure with various mlvm tests
In-Reply-To: <5077060A.6010809@oracle.com>
References: <5074B2A7.6050503@oracle.com>
	<5074C9F3.3000702@oracle.com>	<5075A458.7040900@oracle.com>
	<5075A5E5.9030203@oracle.com> <5075B570.7040406@oracle.com>
	<5076ECCA.2050005@oracle.com> <5077060A.6010809@oracle.com>
Message-ID: <50770628.90202@oracle.com>

Thanks, Serguei!

Jiangli

On 10/11/2012 10:46 AM, serguei.spitsyn at oracle.com wrote:
> Looks good.
>
> Thanks,
> Serguei
>
> On 10/11/12 8:59 AM, Jiangli Zhou wrote:
>> Hi Coleen,
>>
>> Here is the webrev that removes the assert from the latest hsx25 
>> repository with PermGen removal. The assert doesn't add any real 
>> value. I also fixed a small typo.
>>
>>   http://cr.openjdk.java.net/~jiangli/8000459/webrev.01/
>>
>> The previous webrev was based on hsx24, which is pre-PerGen removal. 
>> I should have included that detail in the first review request.
>>
>> Thanks,
>>
>> Jiangli
>>
>> On 10/10/2012 10:50 AM, Coleen Phillimore wrote:
>>>
>>> This change looks good.  Thank you for fixing it.
>>> Coleen
>>>
>>> On 10/10/2012 12:44 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Jiangli,
>>>>
>>>>
>>>> On 10/10/12 9:37 AM, Jiangli Zhou wrote:
>>>>> Hi Serguei,
>>>>>
>>>>> Thanks for the review! Please see comments below.
>>>>>
>>>>> On 10/09/2012 06:05 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Hi Jiangli,
>>>>>>
>>>>>> I'm not very familiar with the pseudo strings, and so, just have 
>>>>>> a question:
>>>>>>
>>>>>> *src/share/vm/prims/jvmtiTagMap.cpp*
>>>>>> 2927             entry = pool->resolved_string_at(i);
>>>>>> 2928 assert(java_lang_String::is_instance(entry) ||
>>>>>> 2929                    pool->is_pseudo_string_at(i), "must be 
>>>>>> string");
>>>>>> I have a little of doubt the above is correct.
>>>>>>
>>>>>> What value the "entry" will have in a case of pseudo string cp 
>>>>>> entry?
>>>>>> Just want to understand what constant pool reference will be 
>>>>>> reported.
>>>>>> Do you see all related failing tests passed?
>>>>>>
>>>>>> Would something like the following be more accurate ?
>>>>>>    entry = pool->is_pseudo_string_at(i) ?
>>>>>>                pool->pseudo_string_at(i, cp_to_object_index(i)) :
>>>>>>                pool->resolved_string_at(i);
>>>>>> assert(java_lang_String::is_instance(entry));
>>>>>>
>>>>>> In this case, a reference from CP to string is reported 
>>>>>> regardless it is pseudo string or not.
>>>>>
>>>>> Those are very good questions. Here is an example of the specific 
>>>>> case with a generated JSR292 java.lang.invoke.LambdaForm$MH class. 
>>>>> The follow are two constant pool entries of the class. Entry 16 is 
>>>>> a "sun/misc/Unsafe" String, which could be patched using a 
>>>>> sun.misc.Unsafe klass oop.
>>>>>
>>>>>         ...
>>>>>         (0016) tag=Utf8 "sun/misc/Unsafe"
>>>>>         (0017) tag=Class "sun/misc/Unsafe"
>>>>>         ...
>>>>>
>>>>> I discussed with John Rose about different ways to fix the 
>>>>> assertion issue. The code you have above uses pseudo_string_at() 
>>>>> to access the 'entry', which is similar to one of the version we 
>>>>> discussed. The current change was chosen as it's the simplest 
>>>>> solution.
>>>>
>>>> I'm Ok with the simplest solution.
>>>>
>>>> Thank you for the details!
>>>> -Serguei
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jiangli
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>> On 10/9/12 4:26 PM, Jiangli Zhou wrote:
>>>>>>> Please review following fix for 8000459:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jiangli/8000459/webrev/
>>>>>>>
>>>>>>> With JSR292, a constant pool String entry could be patched to a 
>>>>>>> non-string oop. The assert in 
>>>>>>> VM_HeapWalkOperation::iterate_over_class() needs to be adjusted 
>>>>>>> to reflect that.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jiangli
>>>>>>
>>>>>
>>>>
>>
>


From christian.thalinger at oracle.com  Thu Oct 11 11:00:02 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 11 Oct 2012 11:00:02 -0700
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1349967309.1682.12.camel@moonlight>
References: <1349967309.1682.12.camel@moonlight>
Message-ID: <3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>


On Oct 11, 2012, at 7:55 AM, Roman Kennke <rkennke at redhat.com> wrote:

> Hello,
> 
> In the recent weeks I worked on the Zero interpreter, to get it to build
> and run with JDK8, and in particular with the latest changes that came
> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> 
> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> 
> A few notes on the patch:
> - Some makefile changes have been necessary to get it to build at all.
> - A bunch of stub functions needed to be added to make the compiler
> happy, they should not be called though.
> - Most of the changes are related to JSR292 stuff, in particular the
> added invokehandle handler, and the changes to invokedynamic resulting
> from how the constant pool entry has changed (e.g. method is now in f1).
> - A lot of code relating to JSR292 could be removed because most of the
> logic has been moved to the (Java) lambda forms.
> - A few native methods have been added (MH.invokeBasic(),
> MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
> 
> With those changes it's possible to build the Zero-JDK with itself, and
> run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
> TCK or such, this would have to wait until all this gets backported to
> JDK7 anyway, and I wanted to get some feedback on the changes first.

You may want to run something like JRuby as well.

> 
> So what do you think?
> 
> And what are the next steps to (hopefully) get those changes committed?
> I guess I need a bug-ID and formal review ?

Yes, you do.  Here is the bug:

8000780: make Zero build and run with JDK8

I'm reviewing the changes right now...

-- Chris

> 
> And in case this is not the correct mailing list, please fwd to and/or
> CC the correct list.
> 
> Thanks and kind regards,
> Roman
> 
> 


From christian.thalinger at oracle.com  Thu Oct 11 11:07:30 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 11 Oct 2012 11:07:30 -0700
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
Message-ID: <E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>


On Oct 11, 2012, at 11:00 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Oct 11, 2012, at 7:55 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
>> Hello,
>> 
>> In the recent weeks I worked on the Zero interpreter, to get it to build
>> and run with JDK8, and in particular with the latest changes that came
>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>> 
>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/

src/share/vm/asm/codeBuffer.cpp:

-  if (dest->blob() == NULL) {
+  if (dest->blob() == NULL && dest_filled != 0x0) {

Do we really need this when you have this:

 static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {

-  memset(to, value, count);
+  if ( count > 0 ) memset(to, value, count);

 }

src/share/vm/interpreter/interpreter.cpp:

-  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
+  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");

Why did you need that change?

-- Chris

>> 
>> A few notes on the patch:
>> - Some makefile changes have been necessary to get it to build at all.
>> - A bunch of stub functions needed to be added to make the compiler
>> happy, they should not be called though.
>> - Most of the changes are related to JSR292 stuff, in particular the
>> added invokehandle handler, and the changes to invokedynamic resulting
>> from how the constant pool entry has changed (e.g. method is now in f1).
>> - A lot of code relating to JSR292 could be removed because most of the
>> logic has been moved to the (Java) lambda forms.
>> - A few native methods have been added (MH.invokeBasic(),
>> MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
>> 
>> With those changes it's possible to build the Zero-JDK with itself, and
>> run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
>> TCK or such, this would have to wait until all this gets backported to
>> JDK7 anyway, and I wanted to get some feedback on the changes first.
> 
> You may want to run something like JRuby as well.
> 
>> 
>> So what do you think?
>> 
>> And what are the next steps to (hopefully) get those changes committed?
>> I guess I need a bug-ID and formal review ?
> 
> Yes, you do.  Here is the bug:
> 
> 8000780: make Zero build and run with JDK8
> 
> I'm reviewing the changes right now...
> 
> -- Chris
> 
>> 
>> And in case this is not the correct mailing list, please fwd to and/or
>> CC the correct list.
>> 
>> Thanks and kind regards,
>> Roman
>> 
>> 
> 


From john.r.rose at oracle.com  Thu Oct 11 12:32:45 2012
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 11 Oct 2012 12:32:45 -0700
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5076C1C2.30408@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com>
Message-ID: <63685177-BB0B-4FA0-B544-DB9933FC2FEF@oracle.com>

On Oct 11, 2012, at 5:55 AM, Nils Loodin wrote:

> Your comments on this issue are great! So here's another version that
> uses an enum instead of std::nothrow_t trickery!
> 
> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/

Yes, this is better.

You introduce new occurrences of std::nothrow_t.  I would rather see these new APIs use something that doesn't mention throws, because "throw" is misleading.  Why not just pass the AllocFailEnum option directly?

Also consider changing existing occurrences of std::nothrow_t to use your enum.  (I realize that there's a difference between statically linking to a non-exiting function, versus passing a variable option to select behavior.  I think that's merely academic in our case.  Someone please correct me if I'm wrong.)

There are only about 30 occurrences of std::nothrow_t in the system, all new.  This is the proverbial camel's nose under the tent.  We can't accept the whole camel.  So let's push him back out.  At least, let's not invite more of him in.

? John

From john.coomes at oracle.com  Thu Oct 11 12:37:45 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 11 Oct 2012 19:37:45 +0000
Subject: hg: hsx/hotspot-main: 4 new changesets
Message-ID: <20121011193745.4B926472C8@hg.openjdk.java.net>

Changeset: dae9821589cc
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/dae9821589cc

Added tag jdk8-b58 for changeset 936702480487

! .hgtags

Changeset: b9d574659206
Author:    katleman
Date:      2012-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/b9d574659206

Added tag jdk8-b59 for changeset dae9821589cc

! .hgtags

Changeset: 4b54d77a6831
Author:    dholmes
Date:      2012-10-09 02:08 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/4b54d77a6831

8000461: Top level build doesn't pass OPENJDK=true through to the hotspot build
Summary: Add OPENJDK to the COMMON_BUILD_ARGUMENTS
Reviewed-by: tbell

! make/Defs-internal.gmk

Changeset: e07f499b9dcc
Author:    katleman
Date:      2012-10-10 14:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/e07f499b9dcc

Merge



From john.coomes at oracle.com  Thu Oct 11 12:37:48 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 11 Oct 2012 19:37:48 +0000
Subject: hg: hsx/hotspot-main/corba: 2 new changesets
Message-ID: <20121011193752.682B1472C9@hg.openjdk.java.net>

Changeset: d54dc53e223e
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d54dc53e223e

Added tag jdk8-b58 for changeset 18462a19f7bd

! .hgtags

Changeset: 207ef43ba69e
Author:    katleman
Date:      2012-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/207ef43ba69e

Added tag jdk8-b59 for changeset d54dc53e223e

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 12:37:57 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 11 Oct 2012 19:37:57 +0000
Subject: hg: hsx/hotspot-main/jaxp: 2 new changesets
Message-ID: <20121011193809.4BAA5472CA@hg.openjdk.java.net>

Changeset: af9e8b0f1900
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/af9e8b0f1900

Added tag jdk8-b58 for changeset 1cb19abb3f7b

! .hgtags

Changeset: 2d1dff5310da
Author:    katleman
Date:      2012-10-04 14:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2d1dff5310da

Added tag jdk8-b59 for changeset af9e8b0f1900

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 12:38:13 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 11 Oct 2012 19:38:13 +0000
Subject: hg: hsx/hotspot-main/jaxws: 2 new changesets
Message-ID: <20121011193820.0F063472CB@hg.openjdk.java.net>

Changeset: ae107401be11
Author:    katleman
Date:      2012-09-27 11:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/ae107401be11

Added tag jdk8-b58 for changeset cac4c3937063

! .hgtags

Changeset: 5c5a65ad5291
Author:    katleman
Date:      2012-10-04 14:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/5c5a65ad5291

Added tag jdk8-b59 for changeset ae107401be11

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 12:40:04 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 11 Oct 2012 19:40:04 +0000
Subject: hg: hsx/hotspot-main/jdk: 64 new changesets
Message-ID: <20121011195519.56FF8472CC@hg.openjdk.java.net>

Changeset: 8a64eeca4450
Author:    jgodinez
Date:      2012-09-10 10:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a64eeca4450

7183516: [macosx]Can't print-out the defined fonts for PrintFont_2D and AntialiasTableTest.
Reviewed-by: bae, prr

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: db828a233f20
Author:    bae
Date:      2012-09-11 13:32 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/db828a233f20

7181199: [macosx] Startup is much slower in headless mode for apps using Fonts
Reviewed-by: jgodinez, prr

! src/macosx/classes/sun/font/CFontManager.java

Changeset: bce9611f1e8f
Author:    lana
Date:      2012-09-14 13:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bce9611f1e8f

Merge

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: 0ecf1a700fca
Author:    bae
Date:      2012-09-17 13:44 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ecf1a700fca

7186799: Regression tests for ImageIO metadata fail on second run
Reviewed-by: prr, bae
Contributed-by: Vadim Pakhnushev <vadim.pakhnushev at oracle.com>

! test/javax/imageio/metadata/BooleanAttributes.java
! test/javax/imageio/metadata/DOML3Node.java
+ test/javax/imageio/metadata/GetChildNames.java
+ test/javax/imageio/metadata/GetObjectMinValue.java
+ test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatTest.java
+ test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatThreadTest.java
+ test/javax/imageio/metadata/IIOMetadataFormat/MetadataTest.java
+ test/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
+ test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatTest.sh
+ test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatThreadTest.sh
+ test/javax/imageio/metadata/IIOMetadataFormatImplTest.java
+ test/javax/imageio/metadata/MetadataFormatPrinter.java
+ test/javax/imageio/metadata/ObjectArrayMaxLength.java
+ test/javax/imageio/metadata/RegisteredFormatsTest.java
+ test/javax/imageio/metadata/RemoveElement.java
+ test/javax/imageio/metadata/SetAttributeNode.java

Changeset: 47442b1b01eb
Author:    kizune
Date:      2012-09-06 14:59 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/47442b1b01eb

7175183: [macosx] Objective-C exception thrown when switching monitor configuration
Reviewed-by: prr, serb

! src/share/classes/sun/awt/image/VolatileSurfaceManager.java

Changeset: d14dc0ae1c2c
Author:    bagiras
Date:      2012-09-06 17:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d14dc0ae1c2c

7153339: InternalError when drawLine with Xor and Antialiasing
Reviewed-by: prr, flar

! src/windows/classes/sun/java2d/ScreenUpdateManager.java

Changeset: b8a1ff892b33
Author:    alexsch
Date:      2012-09-07 13:08 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8a1ff892b33

7194469: Pressing the Enter key results in an alert tone beep when focus is TextField
Reviewed-by: bagiras, denis

! src/windows/native/sun/windows/awt_TextField.cpp

Changeset: 04292c0c943b
Author:    malenkov
Date:      2012-09-11 10:58 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04292c0c943b

7193977: REGRESSION:Java 7's JavaBeans persistence ignoring the "transient" flag on properties
Reviewed-by: rupashka

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

Changeset: 3a2f5544dd00
Author:    serb
Date:      2012-09-12 21:16 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3a2f5544dd00

7124534: [macosx] Submenu title overlaps with Submenu indicator in JPopupMenu
Reviewed-by: art

+ test/javax/swing/JMenuItem/6438430/bug6438430.java

Changeset: aa35dc4d3f70
Author:    bagiras
Date:      2012-09-13 19:53 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aa35dc4d3f70

7186109: Simplify lock machinery for PostEventQueue & EventQueue
Reviewed-by: art, anthony, dholmes

! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/sun/awt/SunToolkit.java
+ test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java

Changeset: 5b7ad5bedbd7
Author:    bagiras
Date:      2012-09-13 21:23 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b7ad5bedbd7

7198318: SunToolkitSubclass.java should be removed
Reviewed-by: serb

- src/macosx/classes/sun/awt/SunToolkitSubclass.java

Changeset: 5444be588d18
Author:    alexsch
Date:      2012-09-14 15:08 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5444be588d18

7197320: [macosx] Full Screen option missing when Window.documentModified
Reviewed-by: anthony

! src/macosx/native/sun/awt/AWTWindow.m

Changeset: 77fdcd3df205
Author:    alexsch
Date:      2012-09-14 15:30 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77fdcd3df205

7196547: [macosx] Implement dead key detection for KeyEvent
Reviewed-by: skovatch, kizune

! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/native/sun/awt/AWTEvent.m
+ test/java/awt/event/KeyEvent/DeadKey/deadKeyMacOSX.java

Changeset: 1785f8335f4d
Author:    VKARNAUK
Date:      2012-09-14 19:51 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1785f8335f4d

6994562: Swing classes (both JTextArea and JTextField) don't support caret width tuning
Reviewed-by: rupashka, art

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/javax/swing/text/DefaultCaret.java
! src/windows/native/sun/windows/awt_DesktopProperties.cpp
! src/windows/native/sun/windows/awt_DesktopProperties.h

Changeset: b6ad3339f3f4
Author:    lana
Date:      2012-09-14 14:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b6ad3339f3f4

Merge


Changeset: 1ed7fec79bee
Author:    leonidr
Date:      2012-09-17 17:25 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ed7fec79bee

7160951: ActionListener called twice for JMenuItem using ScreenMenuBar
Reviewed-by: anthony, serb
Contributed-by: Marco Dinacci <marco.dinacci at gmail.com>

! src/macosx/native/sun/awt/AWTEvent.h
! src/macosx/native/sun/awt/AWTEvent.m
! src/macosx/native/sun/awt/CDragSource.m
! src/macosx/native/sun/awt/CMenuItem.m
! src/macosx/native/sun/awt/DnDUtilities.h
! src/macosx/native/sun/awt/DnDUtilities.m

Changeset: 1d1254af05dd
Author:    kshefov
Date:      2012-09-18 17:38 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d1254af05dd

7190587: Open source and jtreg'ify JAWT regression test
Reviewed-by: anthony, omajid

+ 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

Changeset: a96f5b1d03f9
Author:    lana
Date:      2012-09-19 12:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a96f5b1d03f9

Merge

- src/macosx/classes/sun/awt/SunToolkitSubclass.java

Changeset: 076d0dafea5f
Author:    mgerdin
Date:      2012-09-06 14:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/076d0dafea5f

7195557: NPG: Unexpected number of memory pools
Summary: Update management tests to work with a VM without a permanent generation memory pool
Reviewed-by: rbackman, brutisso, sla, dholmes

! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
! test/java/lang/management/MemoryMXBean/MemoryTest.java

Changeset: 8c6895afe204
Author:    lancea
Date:      2012-09-06 13:16 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8c6895afe204

7192302: Remove JDBCRowSetImpl dependency on java.beans
Reviewed-by: alanb, mchung

! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java

Changeset: 833f4630f3a1
Author:    weijun
Date:      2012-09-07 10:24 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/833f4630f3a1

7196677: diff compares same file to itself in PaddingTest regression test.
Reviewed-by: xuelei

! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java

Changeset: d5d24c08f0dc
Author:    chegar
Date:      2012-09-07 14:00 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d5d24c08f0dc

7032247: java/net/InetAddress/GetLocalHostWithSM.java fails if hostname resolves to loopback address
Summary: TESTBUG
Reviewed-by: chegar, alanb
Contributed-by: Eric Wang <yiming.wang at oracle.com>

! test/java/net/InetAddress/GetLocalHostWithSM.java

Changeset: 3857114d8255
Author:    chegar
Date:      2012-09-07 15:30 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3857114d8255

6354758: rename old test HttpServer classes
Reviewed-by: chegar, michaelm, khazra
Contributed-by: John Zavgren <john.zavgren at oracle.com>

! test/java/net/Authenticator/B4678055.java
! test/java/net/Authenticator/B4722333.java
! test/java/net/Authenticator/B4759514.java
! test/java/net/Authenticator/B4769350.java
! test/java/net/Authenticator/B4921848.java
! test/java/net/Authenticator/B4933582.java
! test/java/net/Authenticator/B4962064.java
! test/java/net/CookieHandler/CookieManagerTest.java
! test/java/net/ProxySelector/LoopbackAddresses.java
! test/java/net/ProxySelector/ProxyTest.java
! test/java/net/URL/PerConnectionProxy.java
! test/java/net/URLConnection/B5052093.java
! test/sun/net/www/AuthHeaderTest.java
! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java
! test/sun/net/www/http/KeepAliveCache/B5045306.java
- test/sun/net/www/httptest/HttpServer.java
! test/sun/net/www/httptest/HttpTransaction.java
+ test/sun/net/www/httptest/TestHttpServer.java
! test/sun/net/www/protocol/http/B6296310.java
! test/sun/net/www/protocol/http/B6299712.java
! test/sun/net/www/protocol/http/RelativeRedirect.java
! test/sun/net/www/protocol/http/ResponseCacheStream.java
! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java
! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java
! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java
+ test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java

Changeset: 7f081e14364e
Author:    mullan
Date:      2012-09-07 12:49 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7f081e14364e

4647343: IDENT variable in sun.security.x509 classes not used
Reviewed-by: mullan
Contributed-by: jason.uh at oracle.com

- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
! src/share/classes/sun/security/x509/X509CertImpl.java
! src/share/classes/sun/security/x509/X509CertInfo.java

Changeset: fffbb33df102
Author:    coffeys
Date:      2012-09-07 21:22 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fffbb33df102

7180362: RFE: Implement date cutover functionality for currency.properties file
Reviewed-by: naoto

! src/share/classes/java/util/Currency.java
! test/java/util/Currency/PropertiesTest.java
! test/java/util/Currency/PropertiesTest.sh
! test/java/util/Currency/currency.properties

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

7195301: XML Signature DOM implementation should not use instanceof to determine type of Node
Reviewed-by: xuelei

! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java
! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java
! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java
! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java
! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java

Changeset: a14d41fd6f51
Author:    mullan
Date:      2012-09-10 09:00 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a14d41fd6f51

Merge

- make/sun/beans/Makefile
- src/share/classes/sun/beans/editors/BooleanEditor.java
- src/share/classes/sun/beans/editors/ByteEditor.java
- src/share/classes/sun/beans/editors/ColorEditor.java
- src/share/classes/sun/beans/editors/DoubleEditor.java
- src/share/classes/sun/beans/editors/EnumEditor.java
- src/share/classes/sun/beans/editors/FloatEditor.java
- src/share/classes/sun/beans/editors/FontEditor.java
- src/share/classes/sun/beans/editors/IntegerEditor.java
- src/share/classes/sun/beans/editors/LongEditor.java
- src/share/classes/sun/beans/editors/NumberEditor.java
- src/share/classes/sun/beans/editors/ShortEditor.java
- src/share/classes/sun/beans/editors/StringEditor.java
- src/share/classes/sun/beans/infos/ComponentBeanInfo.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- src/solaris/classes/sun/awt/X11/XTextTransferHelper.java
- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 657f7cb0da7e
Author:    mullan
Date:      2012-09-10 09:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/657f7cb0da7e

Merge


Changeset: 2598dad44449
Author:    dsamersoff
Date:      2012-09-11 19:58 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2598dad44449

7194597: Typeo in com.sun.management.VMOption.toString()
Summary: VMOption.toString() returns "...(read-only)" if writable "...(read-write)" otherwise.
Reviewed-by: alanb, mchung
Contributed-by: dmytro_sheyko at hotmail.com

! src/share/classes/com/sun/management/VMOption.java

Changeset: 1f7c783e4f13
Author:    dxu
Date:      2012-08-31 13:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1f7c783e4f13

7193406: Clean-up JDK Build Warnings in java.util, java.io
Summary: Clean-up JDK Build Warnings in java.util, java.io Packages
Reviewed-by: smarks, darcy, khazra, dholmes, forax, dl, andrew, aph, omajid, ulfzibis, christos, mduigou

! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/JumboEnumSet.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/PropertyResourceBundle.java
! src/share/classes/java/util/jar/JarVerifier.java
! src/share/classes/java/util/jar/Pack200.java
! src/share/classes/sun/util/PreHashedMap.java

Changeset: 7a16cd3bd2d9
Author:    mullan
Date:      2012-09-12 15:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7a16cd3bd2d9

7196593: java.security.debug=help doesn't list certpath option
Reviewed-by: mullan, wetmore, valeriep
Contributed-by: jason.uh at oracle.com

! src/share/classes/sun/security/util/Debug.java

Changeset: f8c1cf072ba6
Author:    mullan
Date:      2012-09-12 15:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8c1cf072ba6

Merge


Changeset: e095be3820ee
Author:    chegar
Date:      2012-09-13 11:17 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e095be3820ee

7197203: sun/misc/URLClassPath/ClassnameCharTest.sh failed, compile error
Reviewed-by: alanb

! test/sun/misc/URLClassPath/ClassnameCharTest.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh

Changeset: e8a3807de977
Author:    alanb
Date:      2012-09-13 15:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8a3807de977

7197637: (ch) sun.nio.ch.Default* cause providers for other platforms to be included in rt.jar
Reviewed-by: mchung

! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java
! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java

Changeset: eae1384cff39
Author:    mullan
Date:      2012-09-14 10:13 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eae1384cff39

7176627: CertPath/jep124/PreferCRL_SoftFail test fails (Could not determine revocation status)
Reviewed-by: xuelei

! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java
! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/OCSP.java
! src/share/classes/sun/security/provider/certpath/PKIX.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/URICertStore.java
! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java
! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java

Changeset: 34bcbb110bb0
Author:    mullan
Date:      2012-09-14 10:14 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/34bcbb110bb0

Merge

- make/sun/beans/Makefile
- src/share/classes/sun/beans/editors/BooleanEditor.java
- src/share/classes/sun/beans/editors/ByteEditor.java
- src/share/classes/sun/beans/editors/ColorEditor.java
- src/share/classes/sun/beans/editors/DoubleEditor.java
- src/share/classes/sun/beans/editors/EnumEditor.java
- src/share/classes/sun/beans/editors/FloatEditor.java
- src/share/classes/sun/beans/editors/FontEditor.java
- src/share/classes/sun/beans/editors/IntegerEditor.java
- src/share/classes/sun/beans/editors/LongEditor.java
- src/share/classes/sun/beans/editors/NumberEditor.java
- src/share/classes/sun/beans/editors/ShortEditor.java
- src/share/classes/sun/beans/editors/StringEditor.java
- src/share/classes/sun/beans/infos/ComponentBeanInfo.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- src/solaris/classes/sun/awt/X11/XTextTransferHelper.java
- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: c11cec5a9306
Author:    mullan
Date:      2012-09-14 10:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c11cec5a9306

Merge

- test/sun/misc/URLClassPath/ClassnameCharTest.sh

Changeset: 22d7a9f73a59
Author:    mchung
Date:      2012-09-14 09:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/22d7a9f73a59

7193302: Remove ConstructorProperties annotation from java.lang.management.LockInfo
Reviewed-by: alanb, sla, egahlin

! src/share/classes/java/lang/management/LockInfo.java
! src/share/classes/java/lang/management/ThreadInfo.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
+ src/share/classes/sun/management/LockInfoCompositeData.java
! src/share/classes/sun/management/MappedMXBeanType.java
! src/share/classes/sun/management/MonitorInfoCompositeData.java
! src/share/classes/sun/management/ThreadInfoCompositeData.java
! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java

Changeset: 356ff53c9b6d
Author:    lana
Date:      2012-09-14 10:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/356ff53c9b6d

Merge

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

Changeset: 92f3cda88d8e
Author:    mduigou
Date:      2012-09-11 07:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92f3cda88d8e

7189926: Reduce test size for default run. Add additional run enabling alternative hashing.
Reviewed-by: alanb

! test/java/util/Map/Collisions.java

Changeset: 17881ebf811c
Author:    mullan
Date:      2012-09-16 13:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/17881ebf811c

7195409: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest fails with NullPointerException
Reviewed-by: xuelei

! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java
! src/share/classes/sun/security/provider/certpath/BasicChecker.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/ForwardState.java
! src/share/classes/sun/security/provider/certpath/PKIX.java
! src/share/classes/sun/security/provider/certpath/ReverseState.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java

Changeset: 0c3b0a82c4fc
Author:    weijun
Date:      2012-09-17 17:19 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c3b0a82c4fc

7198205: CloseTest fails on mac
Reviewed-by: alanb, chegar, michaelm

! test/ProblemList.txt
! test/java/net/URLClassLoader/closetest/CloseTest.java

Changeset: 39e97f68fa8c
Author:    sla
Date:      2012-09-17 11:27 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39e97f68fa8c

7198846: Add javax/management/remote/mandatory/notif/DiffHBTest.java to ProblemList.txt
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: f56f85040c58
Author:    weijun
Date:      2012-09-17 18:19 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f56f85040c58

7196855: autotest.sh fails on ubuntu because libsoftokn.so not found
Reviewed-by: vinnie

! test/sun/security/tools/keytool/autotest.sh

Changeset: 8a454e92aaf1
Author:    sla
Date:      2012-09-17 12:40 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a454e92aaf1

7198849: Make javax/management/remote/mandatory/notif/ListenerScaleTest.java less timing sensitive
Reviewed-by: alanb

! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java

Changeset: e20a2e6a92f7
Author:    mduigou
Date:      2012-09-17 11:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e20a2e6a92f7

7198988: re-order paramaters for Collision.java @run
Reviewed-by: alanb

! test/java/util/Map/Collisions.java

Changeset: 53ca38f76eaa
Author:    weijun
Date:      2012-09-18 17:38 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/53ca38f76eaa

7198871: cleanup security tests in problem lists with no CR attached
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 95a93f039e5c
Author:    vinnie
Date:      2012-09-18 11:08 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/95a93f039e5c

7198901: correct the field size check when decoding a point on ECC curve
Reviewed-by: xuelei

! src/share/classes/sun/security/ec/ECParameters.java

Changeset: bc5e7ec12717
Author:    dxu
Date:      2012-09-18 13:14 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc5e7ec12717

7142919: TEST_BUG: java/nio/channels/AsyncCloseAndInterrupt.java failing intermittently [sol11]
Reviewed-by: alanb

! test/ProblemList.txt
! test/java/nio/channels/AsyncCloseAndInterrupt.java

Changeset: 88a4f699d233
Author:    xuelei
Date:      2012-09-18 06:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88a4f699d233

7199066: Typo in method name
Reviewed-by: mullan

! 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/SSLSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: 0136fca60652
Author:    naoto
Date:      2012-09-18 10:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0136fca60652

7198984: Add java/text/Bidi/Bug6665028.java to ProblemList.txt
Reviewed-by: alanb
Contributed-by: yiming.wang at oracle.com

! test/ProblemList.txt

Changeset: e7add6d98729
Author:    mduigou
Date:      2012-09-18 11:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7add6d98729

7199249: TEST_BUG : Add /othervm to Collisions.java @run main with -D definitions
Reviewed-by: alanb

! test/java/util/Map/Collisions.java

Changeset: db381a2c0083
Author:    alanb
Date:      2012-09-18 21:21 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/db381a2c0083

7190273: Deprecate com.sun.security.auth.callback.DialogCallbackHandler
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java

Changeset: e143d8f8e477
Author:    dxu
Date:      2012-09-18 14:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e143d8f8e477

7195933: There is incorrect link to "Info-ZIP Application Note 970311" in doc page of Package java.util.zip
Summary: Correct a java doc link in java.util.zip package page
Reviewed-by: chegar, lancea, sherman
Contributed-by: dan.xu at oracle.com

! src/share/classes/java/util/zip/package.html

Changeset: 045a0962b430
Author:    mchung
Date:      2012-09-18 15:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/045a0962b430

7198070: Eliminate static dependency from JMX to java.beans.ConstructorProperties
Reviewed-by: alanb

! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java

Changeset: 5d064862376d
Author:    jgish
Date:      2012-09-19 08:52 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d064862376d

4722265: (spec str) StringBuffer.ensureCapacity() should mention that capacity is mutable
Summary: add usage note to AbstractStringBuilder ensureCapacity()
Reviewed-by: mduigou, dholmes, chegar

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 27182d84a244
Author:    chegar
Date:      2012-09-19 14:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27182d84a244

7199500: Minor typo in AbstractStringBuilder.java header
Reviewed-by: coffeys

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 002717a1418f
Author:    lana
Date:      2012-09-19 12:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/002717a1418f

Merge

- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 3f876919cd58
Author:    lana
Date:      2012-09-24 21:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f876919cd58

Merge

- src/macosx/classes/sun/awt/SunToolkitSubclass.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 4015dec20965
Author:    amurillo
Date:      2012-09-26 13:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4015dec20965

Merge

- src/macosx/classes/sun/awt/SunToolkitSubclass.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
! test/ProblemList.txt
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: c9568c94c4e7
Author:    ohair
Date:      2012-09-21 12:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9568c94c4e7

7191703: jprt cannot build jdk on MacOSX.
Reviewed-by: anthony

! make/common/shared/Defs.gmk
! make/java/jobjc/Makefile

Changeset: d94613ac03d8
Author:    katleman
Date:      2012-09-26 22:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d94613ac03d8

Merge

- src/macosx/classes/sun/awt/SunToolkitSubclass.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: abad1f417bd3
Author:    katleman
Date:      2012-09-27 11:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/abad1f417bd3

Added tag jdk8-b58 for changeset d94613ac03d8

! .hgtags

Changeset: cec8fa02f156
Author:    katleman
Date:      2012-10-04 14:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cec8fa02f156

Added tag jdk8-b59 for changeset abad1f417bd3

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 13:00:17 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 11 Oct 2012 20:00:17 +0000
Subject: hg: hsx/hotspot-main/langtools: 12 new changesets
Message-ID: <20121011200044.434E8472CE@hg.openjdk.java.net>

Changeset: 489905e5018e
Author:    jjg
Date:      2012-09-07 11:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/489905e5018e

7186925: JavapTask passes null to java.io.Writer
Reviewed-by: jjh

! src/share/classes/com/sun/tools/javap/JavapTask.java
+ test/tools/javap/T7186925.java

Changeset: 324b98626f58
Author:    jjg
Date:      2012-09-07 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/324b98626f58

7196774: javac cannot be built with JDK 6 after 7151010
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Annotate.java

Changeset: 1a7c11b22192
Author:    jjg
Date:      2012-09-07 11:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1a7c11b22192

7196760: tree end positions incorrect after anno processing
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/api/EndPositions.java

Changeset: fa85af323d97
Author:    bpatel
Date:      2012-09-08 22:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fa85af323d97

7180906: Javadoc tool does not apply parameter -nosince
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
+ test/com/sun/javadoc/testSinceTag/TestSinceTag.java
+ test/com/sun/javadoc/testSinceTag/pkg1/C1.java

Changeset: b2064a216117
Author:    bpatel
Date:      2012-09-08 22:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b2064a216117

Merge


Changeset: 30c36e23f154
Author:    jjg
Date:      2012-09-13 14:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/30c36e23f154

7177970: fix issues in langtools doc comments
Reviewed-by: mcimadamore

! src/share/classes/com/sun/javadoc/Doc.java
! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/javadoc/Tag.java
! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java
! src/share/classes/com/sun/source/tree/LineMap.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java
! src/share/classes/com/sun/tools/javac/jvm/CRTable.java
! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Lexer.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/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/util/Bits.java
! src/share/classes/com/sun/tools/javac/util/Context.java
! src/share/classes/com/sun/tools/javac/util/Name.java
! src/share/classes/com/sun/tools/javac/util/Position.java
! src/share/classes/com/sun/tools/javadoc/Comment.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/javax/lang/model/util/Elements.java
! src/share/classes/javax/tools/JavaCompiler.java

Changeset: fabfd2710057
Author:    ksrini
Date:      2012-09-14 09:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fabfd2710057

7192073: (javac) minor refactoring of tree maker to help IDEs
Reviewed-by: jjg
Contributed-by: jan.lahoda at oracle.com

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java

Changeset: 8c3c714eb7de
Author:    lana
Date:      2012-09-14 10:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8c3c714eb7de

Merge


Changeset: a433bd8f3ba9
Author:    lana
Date:      2012-09-14 13:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a433bd8f3ba9

Merge


Changeset: 804a3fbc86e2
Author:    lana
Date:      2012-09-24 21:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/804a3fbc86e2

Merge


Changeset: f299927fc316
Author:    katleman
Date:      2012-09-27 11:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f299927fc316

Added tag jdk8-b58 for changeset 804a3fbc86e2

! .hgtags

Changeset: 3d2b98ffcb53
Author:    katleman
Date:      2012-10-04 14:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3d2b98ffcb53

Added tag jdk8-b59 for changeset f299927fc316

! .hgtags


From rkennke at redhat.com  Thu Oct 11 13:51:10 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 11 Oct 2012 22:51:10 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
Message-ID: <1349988670.1682.16.camel@moonlight>

Hi Christian,

Thanks for the fast reply!

> >> In the recent weeks I worked on the Zero interpreter, to get it to build
> >> and run with JDK8, and in particular with the latest changes that came
> >> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> >> 
> >> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> 
> src/share/vm/asm/codeBuffer.cpp:
> 
> -  if (dest->blob() == NULL) {
> +  if (dest->blob() == NULL && dest_filled != 0x0) {
> 
> Do we really need this when you have this:

The above is needed, because the loop above it that initializes
dest_filled is never executed. However, I will change the test to
dest_filled != NULL :-)

>  static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
> 
> -  memset(to, value, count);
> +  if ( count > 0 ) memset(to, value, count);
> 
>  }

Turns out that this is 1. not related to the other change above and 2.
not needed. I'll remove it.

> src/share/vm/interpreter/interpreter.cpp:
> 
> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
> 
> Why did you need that change?

Apparently, before the whole table was initialized, and the methodhandle
related entries left as abstract. Now the methodhandle entries are
simply left to NULL. I suppose we could change the assert to 

assert(_entry_table[kind] == NULL, "previous value must be NULL");

Alternatively, we could fix the code that puts the other entries to also
set the methodhandle entries to AME and go back to the original assert.
What do you think?

Roman

> -- Chris
> 
> >> 
> >> A few notes on the patch:
> >> - Some makefile changes have been necessary to get it to build at all.
> >> - A bunch of stub functions needed to be added to make the compiler
> >> happy, they should not be called though.
> >> - Most of the changes are related to JSR292 stuff, in particular the
> >> added invokehandle handler, and the changes to invokedynamic resulting
> >> from how the constant pool entry has changed (e.g. method is now in f1).
> >> - A lot of code relating to JSR292 could be removed because most of the
> >> logic has been moved to the (Java) lambda forms.
> >> - A few native methods have been added (MH.invokeBasic(),
> >> MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
> >> 
> >> With those changes it's possible to build the Zero-JDK with itself, and
> >> run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
> >> TCK or such, this would have to wait until all this gets backported to
> >> JDK7 anyway, and I wanted to get some feedback on the changes first.
> > 
> > You may want to run something like JRuby as well.
> > 
> >> 
> >> So what do you think?
> >> 
> >> And what are the next steps to (hopefully) get those changes committed?
> >> I guess I need a bug-ID and formal review ?
> > 
> > Yes, you do.  Here is the bug:
> > 
> > 8000780: make Zero build and run with JDK8
> > 
> > I'm reviewing the changes right now...
> > 
> > -- Chris
> > 
> >> 
> >> And in case this is not the correct mailing list, please fwd to and/or
> >> CC the correct list.
> >> 
> >> Thanks and kind regards,
> >> Roman
> >> 
> >> 
> > 
> 



From rkennke at redhat.com  Thu Oct 11 13:58:54 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 11 Oct 2012 22:58:54 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
Message-ID: <1349989134.1682.18.camel@moonlight>

Am Donnerstag, den 11.10.2012, 11:00 -0700 schrieb Christian Thalinger:
> On Oct 11, 2012, at 7:55 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> > Hello,
> > 
> > In the recent weeks I worked on the Zero interpreter, to get it to build
> > and run with JDK8, and in particular with the latest changes that came
> > from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> > 
> > http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> > 
> > A few notes on the patch:
> > - Some makefile changes have been necessary to get it to build at all.
> > - A bunch of stub functions needed to be added to make the compiler
> > happy, they should not be called though.
> > - Most of the changes are related to JSR292 stuff, in particular the
> > added invokehandle handler, and the changes to invokedynamic resulting
> > from how the constant pool entry has changed (e.g. method is now in f1).
> > - A lot of code relating to JSR292 could be removed because most of the
> > logic has been moved to the (Java) lambda forms.
> > - A few native methods have been added (MH.invokeBasic(),
> > MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
> > 
> > With those changes it's possible to build the Zero-JDK with itself, and
> > run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
> > TCK or such, this would have to wait until all this gets backported to
> > JDK7 anyway, and I wanted to get some feedback on the changes first.
> 
> You may want to run something like JRuby as well.

Woa, woa, I never touched this before :-) Is there any particular
program that I should try, that is known to exercise jsr292, or does a
simple helloworld suffice?

Roman



From mikael.vidstedt at oracle.com  Thu Oct 11 14:17:24 2012
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 11 Oct 2012 14:17:24 -0700
Subject: Linux kernel version(s)
Message-ID: <50773764.9020401@oracle.com>


All,

Is anybody out there supporting the latest/greatest development branch 
of HotSpot on Linux kernel version 2.4? The reason I ask is because I'm 
interested in understanding if we can deprecate/remove code that is no 
longer in use.

Thanks,
Mikael


From azeem.jiva at oracle.com  Thu Oct 11 14:58:25 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Thu, 11 Oct 2012 16:58:25 -0500
Subject: Linux kernel version(s)
In-Reply-To: <50773764.9020401@oracle.com>
References: <50773764.9020401@oracle.com>
Message-ID: <50774101.6040005@oracle.com>

As an FYI Kernel version 2.4 was released January 2001.

On 10/11/2012 04:17 PM, Mikael Vidstedt wrote:
>
> All,
>
> Is anybody out there supporting the latest/greatest development branch 
> of HotSpot on Linux kernel version 2.4? The reason I ask is because 
> I'm interested in understanding if we can deprecate/remove code that 
> is no longer in use.
>
> Thanks,
> Mikael
>

-- 
Azeem Jiva
@javawithjiva


From azeem.jiva at oracle.com  Thu Oct 11 14:59:39 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Thu, 11 Oct 2012 16:59:39 -0500
Subject: Linux kernel version(s)
In-Reply-To: <50774101.6040005@oracle.com>
References: <50773764.9020401@oracle.com> <50774101.6040005@oracle.com>
Message-ID: <5077414B.1060000@oracle.com>

Oh and was deprecated in late 2011.


On 10/11/2012 04:58 PM, Azeem Jiva wrote:
> As an FYI Kernel version 2.4 was released January 2001.
>
> On 10/11/2012 04:17 PM, Mikael Vidstedt wrote:
>>
>> All,
>>
>> Is anybody out there supporting the latest/greatest development 
>> branch of HotSpot on Linux kernel version 2.4? The reason I ask is 
>> because I'm interested in understanding if we can deprecate/remove 
>> code that is no longer in use.
>>
>> Thanks,
>> Mikael
>>
>

-- 
Azeem Jiva
@javawithjiva


From john.coomes at oracle.com  Thu Oct 11 20:33:27 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Oct 2012 03:33:27 +0000
Subject: hg: hsx/hotspot-main: Added tag jdk8-b60 for changeset e07f499b9dcc
Message-ID: <20121012033327.3896147302@hg.openjdk.java.net>

Changeset: 20ff117b5090
Author:    katleman
Date:      2012-10-11 09:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/20ff117b5090

Added tag jdk8-b60 for changeset e07f499b9dcc

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 20:33:31 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Oct 2012 03:33:31 +0000
Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b60 for changeset
	207ef43ba69e
Message-ID: <20121012033334.599BC47303@hg.openjdk.java.net>

Changeset: 41bb9e606efd
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/41bb9e606efd

Added tag jdk8-b60 for changeset 207ef43ba69e

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 20:33:38 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Oct 2012 03:33:38 +0000
Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b60 for changeset
	2d1dff5310da
Message-ID: <20121012033350.8453A47304@hg.openjdk.java.net>

Changeset: 6b1db0b41d2f
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/6b1db0b41d2f

Added tag jdk8-b60 for changeset 2d1dff5310da

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 20:33:59 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Oct 2012 03:33:59 +0000
Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b60 for changeset
	5c5a65ad5291
Message-ID: <20121012033405.A084B47305@hg.openjdk.java.net>

Changeset: 97e5e74e2a34
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/97e5e74e2a34

Added tag jdk8-b60 for changeset 5c5a65ad5291

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 20:34:17 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Oct 2012 03:34:17 +0000
Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b60 for changeset
	cec8fa02f156
Message-ID: <20121012033501.A214147306@hg.openjdk.java.net>

Changeset: 869519bc17ce
Author:    katleman
Date:      2012-10-11 09:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/869519bc17ce

Added tag jdk8-b60 for changeset cec8fa02f156

! .hgtags


From john.coomes at oracle.com  Thu Oct 11 20:37:11 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Oct 2012 03:37:11 +0000
Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b60 for changeset
	3d2b98ffcb53
Message-ID: <20121012033716.9457447307@hg.openjdk.java.net>

Changeset: 67f7408d935e
Author:    katleman
Date:      2012-10-11 09:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/67f7408d935e

Added tag jdk8-b60 for changeset 3d2b98ffcb53

! .hgtags


From david.holmes at oracle.com  Thu Oct 11 21:21:01 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Oct 2012 14:21:01 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5076C1C2.30408@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com>
Message-ID: <50779AAD.30108@oracle.com>

Hi Nils,

There are a number of existing bugs/RFEs in this area - not sure we 
needed yet another.

On 11/10/2012 10:55 PM, Nils Loodin wrote:
> Hey guys.
>
> Your comments on this issue are great! So here's another version that
> uses an enum instead of std::nothrow_t trickery!
>
> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/

I dislike the std::nothrow usage that NMT introduced (there aren't even 
any exceptions involved!) but introducing a completely different 
mechanism seems counter-productive. I prefer the "alloc fail strategy" 
approach but would like to see this solved holistically, replacing 
std::nothrow. Given there exist bigger RFE's to have the VM handle all 
OOM situations gracefully rather than just aborting, I'd rather not see 
just another point-patch put in place.

For the record I found the original proposal extremely confusing: 
nothrow_constant vs throw_constant.

Sorry.

David
-----

> Regards,
> Nils Loodin
>
>
>
>
> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>> Keith,
>>
>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>
>> -Dmitry
>>
>>
>>
>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>
>>> Personally, I don't have strong feelings on how this is implemented,
>>> other than it should be done in a way that's maintainable going forward
>>> and easily understandable by future generations of hotspot developers.
>>> With this in mind, the only potential solution that I don't like is
>>> using a boolean with naked true/false values as discriminators.
>>>
>>> Using some sort of "failure mode" parameter is the natural way to do
>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>> std::nothrow_t already has a type and one value, and is already present
>>> in the few places we're interested in, it seemed easy to simple just add
>>> a new value to use. However if this ends up being confusing because
>>> this is not the normal use of std::notype_t, then fine, we can do
>>> something else.
>>>
>>> --
>>> - Keith
>>
>>
>

From david.holmes at oracle.com  Thu Oct 11 21:47:09 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Oct 2012 14:47:09 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <50779AAD.30108@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
Message-ID: <5077A0CD.2030503@oracle.com>

On 12/10/2012 2:21 PM, David Holmes wrote:
> Hi Nils,
>
> There are a number of existing bugs/RFEs in this area - not sure we
> needed yet another.
>
> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>> Hey guys.
>>
>> Your comments on this issue are great! So here's another version that
>> uses an enum instead of std::nothrow_t trickery!
>>
>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>
> I dislike the std::nothrow usage that NMT introduced (there aren't even

Apologies it wasn't NMT that introduced this - it is a bit older than 
that: April 2011. See
https://jbs.oracle.com/bugs/browse/JDK-7036747

and some comments in

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

Till then we had avoided any use of C++ std:: stuff - particularly 
anything related to the exception mechanism, which we don't use at all.

> any exceptions involved!) but introducing a completely different
> mechanism seems counter-productive. I prefer the "alloc fail strategy"
> approach but would like to see this solved holistically, replacing
> std::nothrow. Given there exist bigger RFE's to have the VM handle all
> OOM situations gracefully rather than just aborting, I'd rather not see
> just another point-patch put in place.

The bigger problem is probably still too big to really handle - so 
either copy what we already introduced for CHeapObj to ResourceObj for 
consistency, or replace both with something better.

Cheers,
David
-----

> For the record I found the original proposal extremely confusing:
> nothrow_constant vs throw_constant.
>
> Sorry.
>
> David
> -----
>
>> Regards,
>> Nils Loodin
>>
>>
>>
>>
>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>> Keith,
>>>
>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>
>>> -Dmitry
>>>
>>>
>>>
>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>
>>>> Personally, I don't have strong feelings on how this is implemented,
>>>> other than it should be done in a way that's maintainable going forward
>>>> and easily understandable by future generations of hotspot developers.
>>>> With this in mind, the only potential solution that I don't like is
>>>> using a boolean with naked true/false values as discriminators.
>>>>
>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>> std::nothrow_t already has a type and one value, and is already present
>>>> in the few places we're interested in, it seemed easy to simple just
>>>> add
>>>> a new value to use. However if this ends up being confusing because
>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>> something else.
>>>>
>>>> --
>>>> - Keith
>>>
>>>
>>

From david.holmes at oracle.com  Thu Oct 11 22:06:33 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Oct 2012 15:06:33 +1000
Subject: Fwd: RFR: 8000617: It should be possible to allocate memory
	without the VM dying.
In-Reply-To: <41D8C3D1-6137-4C2B-961C-319CDCB666D5@oracle.com>
References: <292AA604-58D0-4D31-86A0-2DB81A72393C@oracle.com>
	<41D8C3D1-6137-4C2B-961C-319CDCB666D5@oracle.com>
Message-ID: <5077A559.4060307@oracle.com>

This conversation is fragmenting across the two mailing lists - probably 
best to just discuss on the larger one: hotspot-dev.

I missed this response before sending my other responses, so apologies 
for any confusion as I refine my position.

On 11/10/2012 7:12 AM, Nils Loodin wrote:
> On Oct 10, 2012, at 22:29 , Vitaly Davidovich wrote:
>>
>> In allocation.cpp, "dothrow" constant is assigned std::nothrow_t but
>> isn't nothrow_t for *not* throwing? This constant is then used to
>> actually signal oom in one of the methods - seems odd
>>
>>
> std::nothrow is for not throwing, and is of the type std::nothrow_t.
>
> It is a bit of trickery, suggested by Keith McGuigan, which made the
> code I did much simpler.
> which we already had a nothrow_t overload. Having this other nothrow_t,
> which instead means DO throw, we can have this with a default argument
> on the methods
> that could be implemented with both kinds and then have a simple switch
> to see which when it was called with. either it was called with
> std::nothrow, in which case we do not throw on oom, or it was called
> with dothrow, in which case we does.

But we never "throw" anything so having a doThrow variant is even more 
inappropriate than the existing noThrow variant. At least with the 
existing nothrow, we were simply adopting the standard C++ operator new 
definitions to get an operator new that returned null. (If the constant 
had been called std::return_null rather than std::nothrow it would have 
matched our non-exception-based usage of "new" much more cleanly!)

>> Also, in ResourceObject::operator new() there's an assertion that
>> nothrow_t == std::nothrow - what's the purpose? Why would someone use
>> this overload if they're not looking to skip bad_alloc? What sort of
>> error are you thinking of here?
>>
>>
> These are the overloaded operator new():s which takes a std::nothrow_t.
> Since we defined a dothrow of the same type, it would be bad if someone
> accidentally called these operator news with dothrow, instead of
> std::nothrow.
> For instance, someone might do foo = new (dothrow) MyClass() in error.

That's an argument against not having this form of "new" in the first place.

>> Finally, I think the idiomatic way to do this type of stuff is to have
>> a separate overload of the alloc function that accepts nothrow_t
>> whereas you seem to have functions that take nothrow_t as a parameter,
>> but then you check if its the "dothrow"
>>
> It is sort of loosely following the pattern in Thread::operator new,
> which takes a std::nothrow_t and then calls other functions with a boolean.
> Me and Keith argued a bit and came to the conclusion that these function
> calls (" allocate(mySize, false)") would look much clearer in the
> callsite if it read "allocate(mySize, std::nothrow)" instead. otherwise,
> you'd have to dig around to see what was going on.

Okay, so I'm getting a clearer picture here now. There are two levels of 
allocation functions:
- operator new
- other stuff used by operator new

I think std::nothrow should only ever be seen in conjunction with 
operator new - where it belongs. If new then uses other allocation 
functions then they should use a different mechanism - like the Enum - 
to indicate how to handle allocation failures.

If the above "rules" are already violated then we should change the 
existing code.

David
-----

>
>> constant inside to see if oom should be reported. It seems cleaner to
>> have overloads where the one taking nothrow_t automatically means
>> don't throw?
>>
>>
> That kind of implementation actually lead to a lot of boilerplate code
> where the two functions overloaded would each call a third common method
> with a specific boolean.
>
> Hope this clears up stuff!
>
> Regards,
> Nils Loodin
>>
>> Thanks
>>
>> Sent from my phone
>>
>> On Oct 10, 2012 4:02 PM, "Nils Loodin" <nils.loodin at oracle.com
>> <mailto:nils.loodin at oracle.com>> wrote:
>>
>>     Hi all!
>>
>>     When looking to implement a feature where I wanted to do some
>>     allocations without the vm calling vm_exit_no_memory() when not
>>     able to allocate, I discovered this wasn't possible with
>>     ResourceObj-type obects. (It was however implemented in
>>     CHeapObj-type objects.
>>
>>     Here's a patch to implement that.
>>
>>     Now we can use (for instance) jcmd on a running production vm
>>     without fear that we will bring the vm down if the jcmd commands
>>     does allocations.
>>     (The commands themselves have to be implemented with this in mind
>>     though.)
>>
>>     Webrev here:
>>     http://cr.openjdk.java.net/~nloodin/8000617/webrev.01/
>>
>>     Regards,
>>     Nils Loodin
>>
>
>

From david.holmes at oracle.com  Thu Oct 11 22:35:25 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Oct 2012 15:35:25 +1000
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1349967309.1682.12.camel@moonlight>
References: <1349967309.1682.12.camel@moonlight>
Message-ID: <5077AC1D.9030308@oracle.com>

Hi Roman,

Disclaimer: I am not a compiler/interpreter expert :)

Can you explain the need for the changes to the shared code regarding 
MethodHandles and general jsr292 stuff. Are there bugs in the existing 
interpreter, or do these changes only affect the interpreter as used by 
Zero (cpp interpreter vs template interpreter?)

Thanks,
David

On 12/10/2012 12:55 AM, Roman Kennke wrote:
> Hello,
>
> In the recent weeks I worked on the Zero interpreter, to get it to build
> and run with JDK8, and in particular with the latest changes that came
> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>
> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>
> A few notes on the patch:
> - Some makefile changes have been necessary to get it to build at all.
> - A bunch of stub functions needed to be added to make the compiler
> happy, they should not be called though.
> - Most of the changes are related to JSR292 stuff, in particular the
> added invokehandle handler, and the changes to invokedynamic resulting
> from how the constant pool entry has changed (e.g. method is now in f1).
> - A lot of code relating to JSR292 could be removed because most of the
> logic has been moved to the (Java) lambda forms.
> - A few native methods have been added (MH.invokeBasic(),
> MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
>
> With those changes it's possible to build the Zero-JDK with itself, and
> run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
> TCK or such, this would have to wait until all this gets backported to
> JDK7 anyway, and I wanted to get some feedback on the changes first.
>
> So what do you think?
>
> And what are the next steps to (hopefully) get those changes committed?
> I guess I need a bug-ID and formal review ?
>
> And in case this is not the correct mailing list, please fwd to and/or
> CC the correct list.
>
> Thanks and kind regards,
> Roman
>
>

From Alan.Bateman at oracle.com  Fri Oct 12 00:04:25 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 08:04:25 +0100
Subject: Linux kernel version(s)
In-Reply-To: <50773764.9020401@oracle.com>
References: <50773764.9020401@oracle.com>
Message-ID: <5077C0F9.5000005@oracle.com>

On 11/10/2012 22:17, Mikael Vidstedt wrote:
>
> All,
>
> Is anybody out there supporting the latest/greatest development branch 
> of HotSpot on Linux kernel version 2.4? The reason I ask is because 
> I'm interested in understanding if we can deprecate/remove code that 
> is no longer in use.
In the libraries area we have been making use of system calls that are 
 >= 2.6 for some time. There is at some new code in JDK 7 that means it 
will no long build or run on a 2.4 kernel.

-Alan.

From Dmitry.Samersoff at oracle.com  Fri Oct 12 00:32:58 2012
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 12 Oct 2012 11:32:58 +0400
Subject: Linux kernel version(s)
In-Reply-To: <50773764.9020401@oracle.com>
References: <50773764.9020401@oracle.com>
Message-ID: <5077C7AA.7010501@oracle.com>

Mikael,

Typically old kernels resides in embedded space. So we need an answer
from embedded team.

>From the other side I'm not sure jdk7 will ever work on 2.4 today and it
for sure will not work on 2.2.

-Dmitry

On 2012-10-12 01:17, Mikael Vidstedt wrote:
> 
> All,
> 
> Is anybody out there supporting the latest/greatest development branch
> of HotSpot on Linux kernel version 2.4? The reason I ask is because I'm
> interested in understanding if we can deprecate/remove code that is no
> longer in use.
> 
> Thanks,
> Mikael
> 


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

From rkennke at redhat.com  Fri Oct 12 02:09:18 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 12 Oct 2012 11:09:18 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <5077AC1D.9030308@oracle.com>
References: <1349967309.1682.12.camel@moonlight> <5077AC1D.9030308@oracle.com>
Message-ID: <1350032958.1682.29.camel@moonlight>

Hi David,

> Disclaimer: I am not a compiler/interpreter expert :)
> 
> Can you explain the need for the changes to the shared code regarding 
> MethodHandles and general jsr292 stuff. Are there bugs in the existing 
> interpreter, or do these changes only affect the interpreter as used by 
> Zero (cpp interpreter vs template interpreter?)

Sure. First, most changes affect only the zero (cpp) interpreter indeed.
Let me explain the changes by file, for the files not ending in _zero:

bytecodeInterpreter.cpp:
- Added invokehandle instruction handler.
- Modified invokedynamic instruction handler for the changed constant
pool cache entry (method now in f1).
- Some modifications to follow changed APIs: e.g. stuff like cache->f1()
-> f1_as_klass()

bytecodeInterpreter.hpp:
- Removed call_method_handle interpreter command, is no longer needed.

cppInterpreter.cpp
- Added native method-entry for math_pow and math_exp. Those have been
added elsewhere but cppInterpreter has been forgotten.

interpreter.cpp
- Changed assert because _entry_table is no longer initialized with AME
for the method handle entries (see discussion with Christian in same
thread).

vmStructs.cpp:

- Don't do declare_constant(frame::entry_frame_call_wrapper_offset) for
ZERO.

macros.hpp:

- Added macros ZERO_ONLY and SHARK_ONLY, used in, e.g. vmStructs.cpp

Overall, I don't think any of this is really 'shared' (or is
cppInterpreter/bytecodeInterpreter used anywhere else other than zero?)

Kind regards,
Roman

> 
> Thanks,
> David
> 
> On 12/10/2012 12:55 AM, Roman Kennke wrote:
> > Hello,
> >
> > In the recent weeks I worked on the Zero interpreter, to get it to build
> > and run with JDK8, and in particular with the latest changes that came
> > from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> >
> > http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> >
> > A few notes on the patch:
> > - Some makefile changes have been necessary to get it to build at all.
> > - A bunch of stub functions needed to be added to make the compiler
> > happy, they should not be called though.
> > - Most of the changes are related to JSR292 stuff, in particular the
> > added invokehandle handler, and the changes to invokedynamic resulting
> > from how the constant pool entry has changed (e.g. method is now in f1).
> > - A lot of code relating to JSR292 could be removed because most of the
> > logic has been moved to the (Java) lambda forms.
> > - A few native methods have been added (MH.invokeBasic(),
> > MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
> >
> > With those changes it's possible to build the Zero-JDK with itself, and
> > run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
> > TCK or such, this would have to wait until all this gets backported to
> > JDK7 anyway, and I wanted to get some feedback on the changes first.
> >
> > So what do you think?
> >
> > And what are the next steps to (hopefully) get those changes committed?
> > I guess I need a bug-ID and formal review ?
> >
> > And in case this is not the correct mailing list, please fwd to and/or
> > CC the correct list.
> >
> > Thanks and kind regards,
> > Roman
> >
> >



From david.holmes at oracle.com  Fri Oct 12 02:12:14 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Oct 2012 19:12:14 +1000
Subject: Linux kernel version(s)
In-Reply-To: <5077C7AA.7010501@oracle.com>
References: <50773764.9020401@oracle.com> <5077C7AA.7010501@oracle.com>
Message-ID: <5077DEEE.9030303@oracle.com>

On 12/10/2012 5:32 PM, Dmitry Samersoff wrote:
> Mikael,
>
> Typically old kernels resides in embedded space. So we need an answer
> from embedded team.

Actually SE Embedded imposed a 2.6 minimum before SE did :)

http://www.oracle.com/technetwork/java/embedded/resources/se-embeddocs/index.html#sysreqs

It would be nice to see all the LinuxThreads/floating-stack stuff 
disappear :)

David

>> From the other side I'm not sure jdk7 will ever work on 2.4 today and it
> for sure will not work on 2.2.
>
> -Dmitry
>
> On 2012-10-12 01:17, Mikael Vidstedt wrote:
>>
>> All,
>>
>> Is anybody out there supporting the latest/greatest development branch
>> of HotSpot on Linux kernel version 2.4? The reason I ask is because I'm
>> interested in understanding if we can deprecate/remove code that is no
>> longer in use.
>>
>> Thanks,
>> Mikael
>>
>
>

From david.holmes at oracle.com  Fri Oct 12 02:19:10 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Oct 2012 19:19:10 +1000
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1350032958.1682.29.camel@moonlight>
References: <1349967309.1682.12.camel@moonlight> <5077AC1D.9030308@oracle.com>
	<1350032958.1682.29.camel@moonlight>
Message-ID: <5077E08E.9040205@oracle.com>

On 12/10/2012 7:09 PM, Roman Kennke wrote:
> Hi David,
>
>> Disclaimer: I am not a compiler/interpreter expert :)
>>
>> Can you explain the need for the changes to the shared code regarding
>> MethodHandles and general jsr292 stuff. Are there bugs in the existing
>> interpreter, or do these changes only affect the interpreter as used by
>> Zero (cpp interpreter vs template interpreter?)
>
> Sure. First, most changes affect only the zero (cpp) interpreter indeed.
> Let me explain the changes by file, for the files not ending in _zero:

Thanks for clarifying. I wasn't sure if the bytecodeInterpreter files 
were "cpp interpreter" specific. I'll pass this back to the compiler 
experts now :)

David

> bytecodeInterpreter.cpp:
> - Added invokehandle instruction handler.
> - Modified invokedynamic instruction handler for the changed constant
> pool cache entry (method now in f1).
> - Some modifications to follow changed APIs: e.g. stuff like cache->f1()
> ->  f1_as_klass()
>
> bytecodeInterpreter.hpp:
> - Removed call_method_handle interpreter command, is no longer needed.
>
> cppInterpreter.cpp
> - Added native method-entry for math_pow and math_exp. Those have been
> added elsewhere but cppInterpreter has been forgotten.
>
> interpreter.cpp
> - Changed assert because _entry_table is no longer initialized with AME
> for the method handle entries (see discussion with Christian in same
> thread).
>
> vmStructs.cpp:
>
> - Don't do declare_constant(frame::entry_frame_call_wrapper_offset) for
> ZERO.
>
> macros.hpp:
>
> - Added macros ZERO_ONLY and SHARK_ONLY, used in, e.g. vmStructs.cpp
>
> Overall, I don't think any of this is really 'shared' (or is
> cppInterpreter/bytecodeInterpreter used anywhere else other than zero?)
>
> Kind regards,
> Roman
>
>>
>> Thanks,
>> David
>>
>> On 12/10/2012 12:55 AM, Roman Kennke wrote:
>>> Hello,
>>>
>>> In the recent weeks I worked on the Zero interpreter, to get it to build
>>> and run with JDK8, and in particular with the latest changes that came
>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>>>
>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>
>>> A few notes on the patch:
>>> - Some makefile changes have been necessary to get it to build at all.
>>> - A bunch of stub functions needed to be added to make the compiler
>>> happy, they should not be called though.
>>> - Most of the changes are related to JSR292 stuff, in particular the
>>> added invokehandle handler, and the changes to invokedynamic resulting
>>> from how the constant pool entry has changed (e.g. method is now in f1).
>>> - A lot of code relating to JSR292 could be removed because most of the
>>> logic has been moved to the (Java) lambda forms.
>>> - A few native methods have been added (MH.invokeBasic(),
>>> MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
>>>
>>> With those changes it's possible to build the Zero-JDK with itself, and
>>> run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
>>> TCK or such, this would have to wait until all this gets backported to
>>> JDK7 anyway, and I wanted to get some feedback on the changes first.
>>>
>>> So what do you think?
>>>
>>> And what are the next steps to (hopefully) get those changes committed?
>>> I guess I need a bug-ID and formal review ?
>>>
>>> And in case this is not the correct mailing list, please fwd to and/or
>>> CC the correct list.
>>>
>>> Thanks and kind regards,
>>> Roman
>>>
>>>
>
>

From coleen.phillimore at oracle.com  Fri Oct 12 04:23:39 2012
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Fri, 12 Oct 2012 07:23:39 -0400
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1349989134.1682.18.camel@moonlight>
References: <1349967309.1682.12.camel@moonlight>	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<1349989134.1682.18.camel@moonlight>
Message-ID: <5077FDBB.6060609@oracle.com>


Hi,
I looked at this briefly and it looks okay from the cpp interpreter 
part.  Thank you for getting zero working again.   We tried to keep it 
in sync with the permgen removal changes but didn't regularly test 
this.   Hello world as a test for this is probably enough to verify your 
changes to the non-JSR292 part.
For JSR292 testing, you need to get a full jdk repository and go to the 
jdk/test/java/lang/invoke and run the tests with jtreg.   How to run and 
install jtreg is on the openjdk pages, and it's happily easy to do.

Thanks,
Coleen

On 10/11/2012 4:58 PM, Roman Kennke wrote:
> Am Donnerstag, den 11.10.2012, 11:00 -0700 schrieb Christian Thalinger:
>> On Oct 11, 2012, at 7:55 AM, Roman Kennke<rkennke at redhat.com>  wrote:
>>
>>> Hello,
>>>
>>> In the recent weeks I worked on the Zero interpreter, to get it to build
>>> and run with JDK8, and in particular with the latest changes that came
>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>>>
>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>
>>> A few notes on the patch:
>>> - Some makefile changes have been necessary to get it to build at all.
>>> - A bunch of stub functions needed to be added to make the compiler
>>> happy, they should not be called though.
>>> - Most of the changes are related to JSR292 stuff, in particular the
>>> added invokehandle handler, and the changes to invokedynamic resulting
>>> from how the constant pool entry has changed (e.g. method is now in f1).
>>> - A lot of code relating to JSR292 could be removed because most of the
>>> logic has been moved to the (Java) lambda forms.
>>> - A few native methods have been added (MH.invokeBasic(),
>>> MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
>>>
>>> With those changes it's possible to build the Zero-JDK with itself, and
>>> run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
>>> TCK or such, this would have to wait until all this gets backported to
>>> JDK7 anyway, and I wanted to get some feedback on the changes first.
>> You may want to run something like JRuby as well.
> Woa, woa, I never touched this before :-) Is there any particular
> program that I should try, that is known to exercise jsr292, or does a
> simple helloworld suffice?
>
> Roman
>
>

From rkennke at redhat.com  Fri Oct 12 05:20:12 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 12 Oct 2012 14:20:12 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <5077FDBB.6060609@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<1349989134.1682.18.camel@moonlight> <5077FDBB.6060609@oracle.com>
Message-ID: <1350044412.1682.31.camel@moonlight>

Am Freitag, den 12.10.2012, 07:23 -0400 schrieb Coleen Phillmore:
> Hi,
> I looked at this briefly and it looks okay from the cpp interpreter 
> part.  Thank you for getting zero working again.   We tried to keep it 
> in sync with the permgen removal changes but didn't regularly test 
> this.   Hello world as a test for this is probably enough to verify your 
> changes to the non-JSR292 part.
> For JSR292 testing, you need to get a full jdk repository and go to the 
> jdk/test/java/lang/invoke and run the tests with jtreg.   How to run and 
> install jtreg is on the openjdk pages, and it's happily easy to do.

Yep, I did run these tests and they all pass, except CallSiteTest which
times out because Zero is too slow, but tweaking the test to do fewer
loops makes it pass as well.

Roman



From nils.loodin at oracle.com  Fri Oct 12 06:14:23 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Fri, 12 Oct 2012 15:14:23 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5077A0CD.2030503@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com>
Message-ID: <507817AF.1040900@oracle.com>


Hey guys!

Thanks for yet another round of informative code reviews!
So I got rid of all the instances of std::nothrow throughout the code 
and replaced them with a new shiny and descriptive enum.

Was able to fold together a few specialized operator new() because of 
it, with more shared code as a result.

What do you think now?
http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/

Have a nice weekend!

Regards,
Nils Loodin


On 10/12/2012 06:47 AM, David Holmes wrote:
> On 12/10/2012 2:21 PM, David Holmes wrote:
>> Hi Nils,
>>
>> There are a number of existing bugs/RFEs in this area - not sure we
>> needed yet another.
>>
>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>> Hey guys.
>>>
>>> Your comments on this issue are great! So here's another version that
>>> uses an enum instead of std::nothrow_t trickery!
>>>
>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>
>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>
> Apologies it wasn't NMT that introduced this - it is a bit older than
> that: April 2011. See
> https://jbs.oracle.com/bugs/browse/JDK-7036747
>
> and some comments in
>
> https://jbs.oracle.com/bugs/browse/JDK-4719004
>
> Till then we had avoided any use of C++ std:: stuff - particularly
> anything related to the exception mechanism, which we don't use at all.
>
>> any exceptions involved!) but introducing a completely different
>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>> approach but would like to see this solved holistically, replacing
>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>> OOM situations gracefully rather than just aborting, I'd rather not see
>> just another point-patch put in place.
>
> The bigger problem is probably still too big to really handle - so
> either copy what we already introduced for CHeapObj to ResourceObj for
> consistency, or replace both with something better.
>
> Cheers,
> David
> -----
>
>> For the record I found the original proposal extremely confusing:
>> nothrow_constant vs throw_constant.
>>
>> Sorry.
>>
>> David
>> -----
>>
>>> Regards,
>>> Nils Loodin
>>>
>>>
>>>
>>>
>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>> Keith,
>>>>
>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>>
>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>
>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>> other than it should be done in a way that's maintainable going
>>>>> forward
>>>>> and easily understandable by future generations of hotspot developers.
>>>>> With this in mind, the only potential solution that I don't like is
>>>>> using a boolean with naked true/false values as discriminators.
>>>>>
>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>> std::nothrow_t already has a type and one value, and is already
>>>>> present
>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>> add
>>>>> a new value to use. However if this ends up being confusing because
>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>> something else.
>>>>>
>>>>> --
>>>>> - Keith
>>>>
>>>>
>>>


From vitalyd at gmail.com  Fri Oct 12 06:40:32 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 12 Oct 2012 09:40:32 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507817AF.1040900@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
Message-ID: <CAHjP37Hv6wQwGb1jYuFCWsUpDFahPaC1nOWH_7-PJVrrTbu5kg@mail.gmail.com>

Hey Nils,

I'm getting a 404 on that link - is it just me?

Thanks

Sent from my phone
On Oct 12, 2012 9:17 AM, "Nils Loodin" <nils.loodin at oracle.com> wrote:

>
> Hey guys!
>
> Thanks for yet another round of informative code reviews!
> So I got rid of all the instances of std::nothrow throughout the code and
> replaced them with a new shiny and descriptive enum.
>
> Was able to fold together a few specialized operator new() because of it,
> with more shared code as a result.
>
> What do you think now?
> http://cr.openjdk.java.net/~**nloodin/8000617/webrev.04/<http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/>
>
> Have a nice weekend!
>
> Regards,
> Nils Loodin
>
>
> On 10/12/2012 06:47 AM, David Holmes wrote:
>
>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>
>>> Hi Nils,
>>>
>>> There are a number of existing bugs/RFEs in this area - not sure we
>>> needed yet another.
>>>
>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>
>>>> Hey guys.
>>>>
>>>> Your comments on this issue are great! So here's another version that
>>>> uses an enum instead of std::nothrow_t trickery!
>>>>
>>>> http://cr.openjdk.java.net/~**nloodin/8000617/webrev.03/<http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/>
>>>>
>>>
>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>>
>>
>> Apologies it wasn't NMT that introduced this - it is a bit older than
>> that: April 2011. See
>> https://jbs.oracle.com/bugs/**browse/JDK-7036747<https://jbs.oracle.com/bugs/browse/JDK-7036747>
>>
>> and some comments in
>>
>> https://jbs.oracle.com/bugs/**browse/JDK-4719004<https://jbs.oracle.com/bugs/browse/JDK-4719004>
>>
>> Till then we had avoided any use of C++ std:: stuff - particularly
>> anything related to the exception mechanism, which we don't use at all.
>>
>>  any exceptions involved!) but introducing a completely different
>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>> approach but would like to see this solved holistically, replacing
>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>> just another point-patch put in place.
>>>
>>
>> The bigger problem is probably still too big to really handle - so
>> either copy what we already introduced for CHeapObj to ResourceObj for
>> consistency, or replace both with something better.
>>
>> Cheers,
>> David
>> -----
>>
>>  For the record I found the original proposal extremely confusing:
>>> nothrow_constant vs throw_constant.
>>>
>>> Sorry.
>>>
>>> David
>>> -----
>>>
>>>  Regards,
>>>> Nils Loodin
>>>>
>>>>
>>>>
>>>>
>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>
>>>>> Keith,
>>>>>
>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>>
>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>
>>>>>>
>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>> other than it should be done in a way that's maintainable going
>>>>>> forward
>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>
>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>> present
>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>> add
>>>>>> a new value to use. However if this ends up being confusing because
>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>> something else.
>>>>>>
>>>>>> --
>>>>>> - Keith
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>

From coleen.phillimore at oracle.com  Fri Oct 12 06:50:01 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 12 Oct 2012 09:50:01 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507817AF.1040900@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
Message-ID: <50782009.3030507@oracle.com>


I'm sorry for not speaking sooner, but I disagreed with removing the 
std::nothrow parameter.   It's standard C++ which is better than our 
inventing our own things.  I did like having an enum to decide whether 
you passed std::nothrow instead of the strange dothrow you had in review 
#1.  I think I would have liked review #2, but I didn't have time to 
look at it.    I just looked at it now:  _03 looks _really_ good.  Your 
_04 review didn't load.

Coleen

On 10/12/2012 9:14 AM, Nils Loodin wrote:
>
> Hey guys!
>
> Thanks for yet another round of informative code reviews!
> So I got rid of all the instances of std::nothrow throughout the code 
> and replaced them with a new shiny and descriptive enum.
>
> Was able to fold together a few specialized operator new() because of 
> it, with more shared code as a result.
>
> What do you think now?
> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>
> Have a nice weekend!
>
> Regards,
> Nils Loodin
>
>
> On 10/12/2012 06:47 AM, David Holmes wrote:
>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>> Hi Nils,
>>>
>>> There are a number of existing bugs/RFEs in this area - not sure we
>>> needed yet another.
>>>
>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>> Hey guys.
>>>>
>>>> Your comments on this issue are great! So here's another version that
>>>> uses an enum instead of std::nothrow_t trickery!
>>>>
>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>
>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>
>> Apologies it wasn't NMT that introduced this - it is a bit older than
>> that: April 2011. See
>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>
>> and some comments in
>>
>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>
>> Till then we had avoided any use of C++ std:: stuff - particularly
>> anything related to the exception mechanism, which we don't use at all.
>>
>>> any exceptions involved!) but introducing a completely different
>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>> approach but would like to see this solved holistically, replacing
>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>> just another point-patch put in place.
>>
>> The bigger problem is probably still too big to really handle - so
>> either copy what we already introduced for CHeapObj to ResourceObj for
>> consistency, or replace both with something better.
>>
>> Cheers,
>> David
>> -----
>>
>>> For the record I found the original proposal extremely confusing:
>>> nothrow_constant vs throw_constant.
>>>
>>> Sorry.
>>>
>>> David
>>> -----
>>>
>>>> Regards,
>>>> Nils Loodin
>>>>
>>>>
>>>>
>>>>
>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>> Keith,
>>>>>
>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>>
>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>
>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>> other than it should be done in a way that's maintainable going
>>>>>> forward
>>>>>> and easily understandable by future generations of hotspot 
>>>>>> developers.
>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>
>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>> present
>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>> add
>>>>>> a new value to use. However if this ends up being confusing because
>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>> something else.
>>>>>>
>>>>>> -- 
>>>>>> - Keith
>>>>>
>>>>>
>>>>
>

From nils.loodin at oracle.com  Fri Oct 12 07:17:05 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Fri, 12 Oct 2012 16:17:05 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <50782009.3030507@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<50782009.3030507@oracle.com>
Message-ID: <65240B48-9606-492A-8756-1D5DD8BB0115@oracle.com>

Whoops, forgot to scp it.. Now its up!

Regards,
Nisse



12 okt 2012 kl. 15:50 skrev Coleen Phillimore <coleen.phillimore at oracle.com>:

> 
> I'm sorry for not speaking sooner, but I disagreed with removing the std::nothrow parameter.   It's standard C++ which is better than our inventing our own things.  I did like having an enum to decide whether you passed std::nothrow instead of the strange dothrow you had in review #1.  I think I would have liked review #2, but I didn't have time to look at it.    I just looked at it now:  _03 looks _really_ good.  Your _04 review didn't load.
> 
> Coleen
> 
> On 10/12/2012 9:14 AM, Nils Loodin wrote:
>> 
>> Hey guys!
>> 
>> Thanks for yet another round of informative code reviews!
>> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
>> 
>> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
>> 
>> What do you think now?
>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>> 
>> Have a nice weekend!
>> 
>> Regards,
>> Nils Loodin
>> 
>> 
>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>> Hi Nils,
>>>> 
>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>> needed yet another.
>>>> 
>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>> Hey guys.
>>>>> 
>>>>> Your comments on this issue are great! So here's another version that
>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>> 
>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>> 
>>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>> 
>>> Apologies it wasn't NMT that introduced this - it is a bit older than
>>> that: April 2011. See
>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>> 
>>> and some comments in
>>> 
>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>> 
>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>> anything related to the exception mechanism, which we don't use at all.
>>> 
>>>> any exceptions involved!) but introducing a completely different
>>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>>> approach but would like to see this solved holistically, replacing
>>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>>> just another point-patch put in place.
>>> 
>>> The bigger problem is probably still too big to really handle - so
>>> either copy what we already introduced for CHeapObj to ResourceObj for
>>> consistency, or replace both with something better.
>>> 
>>> Cheers,
>>> David
>>> -----
>>> 
>>>> For the record I found the original proposal extremely confusing:
>>>> nothrow_constant vs throw_constant.
>>>> 
>>>> Sorry.
>>>> 
>>>> David
>>>> -----
>>>> 
>>>>> Regards,
>>>>> Nils Loodin
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>> Keith,
>>>>>> 
>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>> 
>>>>>> -Dmitry
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>> 
>>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>> forward
>>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>> 
>>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>> present
>>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>>> add
>>>>>>> a new value to use. However if this ends up being confusing because
>>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>>> something else.
>>>>>>> 
>>>>>>> -- 
>>>>>>> - Keith
>> 

From keith.mcguigan at oracle.com  Fri Oct 12 07:25:39 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Fri, 12 Oct 2012 10:25:39 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507817AF.1040900@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
Message-ID: <1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>


May as well lift the allocation fail strategy up into Thread::allocate() as well, replacing the boolean parameter there.

I think you're replacements of new(std::nothrow) XXX() wit new (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to replace it with RETURN_NULL.

--
- Keith

On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:

> 
> Hey guys!
> 
> Thanks for yet another round of informative code reviews!
> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
> 
> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
> 
> What do you think now?
> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
> 
> Have a nice weekend!
> 
> Regards,
> Nils Loodin
> 
> 
> On 10/12/2012 06:47 AM, David Holmes wrote:
>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>> Hi Nils,
>>> 
>>> There are a number of existing bugs/RFEs in this area - not sure we
>>> needed yet another.
>>> 
>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>> Hey guys.
>>>> 
>>>> Your comments on this issue are great! So here's another version that
>>>> uses an enum instead of std::nothrow_t trickery!
>>>> 
>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>> 
>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>> 
>> Apologies it wasn't NMT that introduced this - it is a bit older than
>> that: April 2011. See
>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>> 
>> and some comments in
>> 
>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>> 
>> Till then we had avoided any use of C++ std:: stuff - particularly
>> anything related to the exception mechanism, which we don't use at all.
>> 
>>> any exceptions involved!) but introducing a completely different
>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>> approach but would like to see this solved holistically, replacing
>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>> just another point-patch put in place.
>> 
>> The bigger problem is probably still too big to really handle - so
>> either copy what we already introduced for CHeapObj to ResourceObj for
>> consistency, or replace both with something better.
>> 
>> Cheers,
>> David
>> -----
>> 
>>> For the record I found the original proposal extremely confusing:
>>> nothrow_constant vs throw_constant.
>>> 
>>> Sorry.
>>> 
>>> David
>>> -----
>>> 
>>>> Regards,
>>>> Nils Loodin
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>> Keith,
>>>>> 
>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>> 
>>>>> -Dmitry
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>> 
>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>> other than it should be done in a way that's maintainable going
>>>>>> forward
>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>> 
>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>> present
>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>> add
>>>>>> a new value to use. However if this ends up being confusing because
>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>> something else.
>>>>>> 
>>>>>> --
>>>>>> - Keith
>>>>> 
>>>>> 
>>>> 
> 


From nils.loodin at oracle.com  Fri Oct 12 07:40:04 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Fri, 12 Oct 2012 16:40:04 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
Message-ID: <4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>





12 okt 2012 kl. 16:25 skrev Keith McGuigan <keith.mcguigan at oracle.com>:

> 
> May as well lift the allocation fail strategy up into Thread::allocate() as well, replacing the boolean parameter there.
> 
Ah, good idea.

> I think you're replacements of new(std::nothrow) XXX() wit new (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to replace it with RETURN_NULL.
> 
> -
Argh, darn, you're right of course.

Will fix.

> - Keith
> 
> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
> 
>> 
>> Hey guys!
>> 
>> Thanks for yet another round of informative code reviews!
>> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
>> 
>> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
>> 
>> What do you think now?
>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>> 
>> Have a nice weekend!
>> 
>> Regards,
>> Nils Loodin
>> 
>> 
>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>> Hi Nils,
>>>> 
>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>> needed yet another.
>>>> 
>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>> Hey guys.
>>>>> 
>>>>> Your comments on this issue are great! So here's another version that
>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>> 
>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>> 
>>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>> 
>>> Apologies it wasn't NMT that introduced this - it is a bit older than
>>> that: April 2011. See
>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>> 
>>> and some comments in
>>> 
>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>> 
>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>> anything related to the exception mechanism, which we don't use at all.
>>> 
>>>> any exceptions involved!) but introducing a completely different
>>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>>> approach but would like to see this solved holistically, replacing
>>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>>> just another point-patch put in place.
>>> 
>>> The bigger problem is probably still too big to really handle - so
>>> either copy what we already introduced for CHeapObj to ResourceObj for
>>> consistency, or replace both with something better.
>>> 
>>> Cheers,
>>> David
>>> -----
>>> 
>>>> For the record I found the original proposal extremely confusing:
>>>> nothrow_constant vs throw_constant.
>>>> 
>>>> Sorry.
>>>> 
>>>> David
>>>> -----
>>>> 
>>>>> Regards,
>>>>> Nils Loodin
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>> Keith,
>>>>>> 
>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>> 
>>>>>> -Dmitry
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>> 
>>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>> forward
>>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>> 
>>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>> present
>>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>>> add
>>>>>>> a new value to use. However if this ends up being confusing because
>>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>>> something else.
>>>>>>> 
>>>>>>> --
>>>>>>> - Keith
> 

From rkennke at redhat.com  Fri Oct 12 05:22:03 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 12 Oct 2012 14:22:03 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <5077FDBB.6060609@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<1349989134.1682.18.camel@moonlight> <5077FDBB.6060609@oracle.com>
Message-ID: <1350044523.1682.33.camel@moonlight>

Am Freitag, den 12.10.2012, 07:23 -0400 schrieb Coleen Phillmore:
> Hi,
> I looked at this briefly and it looks okay from the cpp interpreter 
> part.  Thank you for getting zero working again.   We tried to keep it 
> in sync with the permgen removal changes but didn't regularly test 
> this.   Hello world as a test for this is probably enough to verify your 
> changes to the non-JSR292 part.
> For JSR292 testing, you need to get a full jdk repository and go to the 
> jdk/test/java/lang/invoke and run the tests with jtreg.   How to run and 
> install jtreg is on the openjdk pages, and it's happily easy to do.

Ah, and before you mention it as well, I downloaded and run JRuby, the
examples that ship with JRuby run just as well with Zero as they do with
x86 hotspot. However, I am not sure if this exercises JSR292 or not, or
what would be necessary to do so, etc.

Roman



From coleen.phillimore at oracle.com  Fri Oct 12 08:03:23 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 12 Oct 2012 11:03:23 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
Message-ID: <5078313B.60404@oracle.com>


I still prefer webrev 03 to webrev 04.   std::nothrow as a parameter 
means something to any C++ developer and AllocationStrategy::OOM only 
means something to a hotspot developer.  I think we should use the 
standard C++ apis when possible.  The duplication of operator new is not 
significant.   Plus if someone adds new (std::nothrow) call or you 
forgot to clean up one, it think it will overload to the std::operator 
new() which could lead to a subtle bug.

Coleen

On 10/12/2012 10:40 AM, Nils Loodin wrote:
>
>
>
> 12 okt 2012 kl. 16:25 skrev Keith McGuigan<keith.mcguigan at oracle.com>:
>
>> May as well lift the allocation fail strategy up into Thread::allocate() as well, replacing the boolean parameter there.
>>
> Ah, good idea.
>
>> I think you're replacements of new(std::nothrow) XXX() wit new (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to replace it with RETURN_NULL.
>>
>> -
> Argh, darn, you're right of course.
>
> Will fix.
>
>> - Keith
>>
>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>
>>> Hey guys!
>>>
>>> Thanks for yet another round of informative code reviews!
>>> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
>>>
>>> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
>>>
>>> What do you think now?
>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>
>>> Have a nice weekend!
>>>
>>> Regards,
>>> Nils Loodin
>>>
>>>
>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>> Hi Nils,
>>>>>
>>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>>> needed yet another.
>>>>>
>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>> Hey guys.
>>>>>>
>>>>>> Your comments on this issue are great! So here's another version that
>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>
>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>>> Apologies it wasn't NMT that introduced this - it is a bit older than
>>>> that: April 2011. See
>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>
>>>> and some comments in
>>>>
>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>
>>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>>> anything related to the exception mechanism, which we don't use at all.
>>>>
>>>>> any exceptions involved!) but introducing a completely different
>>>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>>>> approach but would like to see this solved holistically, replacing
>>>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>>>> just another point-patch put in place.
>>>> The bigger problem is probably still too big to really handle - so
>>>> either copy what we already introduced for CHeapObj to ResourceObj for
>>>> consistency, or replace both with something better.
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>> For the record I found the original proposal extremely confusing:
>>>>> nothrow_constant vs throw_constant.
>>>>>
>>>>> Sorry.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Regards,
>>>>>> Nils Loodin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>> Keith,
>>>>>>>
>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>>> forward
>>>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>>>
>>>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>>> present
>>>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>>>> add
>>>>>>>> a new value to use. However if this ends up being confusing because
>>>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>>>> something else.
>>>>>>>>
>>>>>>>> --
>>>>>>>> - Keith

From nils.loodin at oracle.com  Fri Oct 12 08:40:04 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Fri, 12 Oct 2012 17:40:04 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <5078313B.60404@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
Message-ID: <068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>

So in general we have two competing wishes here:

1. Use std::nothrow, in operator new() and enum in the allocation methods. (basically webrev 03)
Pros: more c++ standard-ish
cons: more boiler plate, not descriptive of what actually happens, two different mechanisms.


2. Use enums everywhere (basically a bugfree version of 04):
pros: more accurate description, cleaner implementation
cons: it's an instance of "not invented here"-syndrom, ie, we're making up our own stuff.

So.. discuss! John, what do you think having seen the different implementations? It would be nice to be able to get in any version of it so I can develop the feature that will depend on it... :)

Regards,
Nisse

On Oct 12, 2012, at 17:03 , Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> 
> I still prefer webrev 03 to webrev 04.   std::nothrow as a parameter means something to any C++ developer and AllocationStrategy::OOM only means something to a hotspot developer.  I think we should use the standard C++ apis when possible.  The duplication of operator new is not significant.   Plus if someone adds new (std::nothrow) call or you forgot to clean up one, it think it will overload to the std::operator new() which could lead to a subtle bug.
> 
> Coleen
> 
> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>> 
>> 
>> 
>> 12 okt 2012 kl. 16:25 skrev Keith McGuigan<keith.mcguigan at oracle.com>:
>> 
>>> May as well lift the allocation fail strategy up into Thread::allocate() as well, replacing the boolean parameter there.
>>> 
>> Ah, good idea.
>> 
>>> I think you're replacements of new(std::nothrow) XXX() wit new (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to replace it with RETURN_NULL.
>>> 
>>> -
>> Argh, darn, you're right of course.
>> 
>> Will fix.
>> 
>>> - Keith
>>> 
>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>> 
>>>> Hey guys!
>>>> 
>>>> Thanks for yet another round of informative code reviews!
>>>> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
>>>> 
>>>> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
>>>> 
>>>> What do you think now?
>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>> 
>>>> Have a nice weekend!
>>>> 
>>>> Regards,
>>>> Nils Loodin
>>>> 
>>>> 
>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>> Hi Nils,
>>>>>> 
>>>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>>>> needed yet another.
>>>>>> 
>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>> Hey guys.
>>>>>>> 
>>>>>>> Your comments on this issue are great! So here's another version that
>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>>>> Apologies it wasn't NMT that introduced this - it is a bit older than
>>>>> that: April 2011. See
>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>> 
>>>>> and some comments in
>>>>> 
>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>> 
>>>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>>>> anything related to the exception mechanism, which we don't use at all.
>>>>> 
>>>>>> any exceptions involved!) but introducing a completely different
>>>>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>>>>> approach but would like to see this solved holistically, replacing
>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>>>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>>>>> just another point-patch put in place.
>>>>> The bigger problem is probably still too big to really handle - so
>>>>> either copy what we already introduced for CHeapObj to ResourceObj for
>>>>> consistency, or replace both with something better.
>>>>> 
>>>>> Cheers,
>>>>> David
>>>>> -----
>>>>> 
>>>>>> For the record I found the original proposal extremely confusing:
>>>>>> nothrow_constant vs throw_constant.
>>>>>> 
>>>>>> Sorry.
>>>>>> 
>>>>>> David
>>>>>> -----
>>>>>> 
>>>>>>> Regards,
>>>>>>> Nils Loodin
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>> Keith,
>>>>>>>> 
>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>>>> 
>>>>>>>> -Dmitry
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>>>> forward
>>>>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>>>> 
>>>>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>>>> present
>>>>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>>>>> add
>>>>>>>>> a new value to use. However if this ends up being confusing because
>>>>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>>>>> something else.
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> - Keith


From christian.thalinger at oracle.com  Fri Oct 12 10:26:53 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 12 Oct 2012 10:26:53 -0700
Subject: RFR (S): 7197424: update copyright year to match last edit in
	jdk8 hotspot repository
In-Reply-To: <50738120.60903@oracle.com>
References: <50737029.9010900@oracle.com> <50738120.60903@oracle.com>
Message-ID: <A3444267-B814-4C40-89F5-42ED475BBE1A@oracle.com>


On Oct 8, 2012, at 6:42 PM, David Holmes <David.Holmes at oracle.com> wrote:

> Hi Mikael,
> 
> On 9/10/2012 10:30 AM, Mikael Vidstedt wrote:
>> Can I please get a couple of reviews of the below change?
>> 
>> Don't be scared by the size of the change, even though it touches many
>> files (271 to be exact) the change is the same for all of them -
>> updating the copyright year in the header. The change was created using
>> the make/scripts/update_copyright_year.sh script from the JDK.
>> 
>> http://cr.openjdk.java.net/~mikael/7197424/webrev.00/webrev/
> 
> I've verified that the copyrights have been updated to 2012.
> 
> I can't (well won't :) ) validate that they should have been updated to 2012. I did check a couple and saw that JSR-292 changes seem t be involved a lot. ;-)

Thank you.  We did our best ;-)  -- Chris

> 
> Personally I'd prefer to see file copyrights always updated at modification time (preferably automagically!) rather than in bulk later - as later no one is validating the change. Hotspot always tended to work this way in the past, whereas the JDK did/does not. There are pros and cons either way.
> 
> Cheers,
> David
> 
>> Thanks,
>> Mikael
>> 


From vladimir.kozlov at oracle.com  Fri Oct 12 11:13:33 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Fri, 12 Oct 2012 18:13:33 +0000
Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets
Message-ID: <20121012181354.D294747330@hg.openjdk.java.net>

Changeset: c3e799c37717
Author:    vlivanov
Date:      2012-10-05 18:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c3e799c37717

7177003: C1: LogCompilation support
Summary: add LogCompilation support in C1 - both client and tiered mode.
Reviewed-by: twisti, kvn

! src/os/linux/vm/vmError_linux.cpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compileLog.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/ostream.cpp

Changeset: 9a9b6e05ffb4
Author:    vlivanov
Date:      2012-10-05 19:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9a9b6e05ffb4

8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64
Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore.
Reviewed-by: twisti, kvn

! src/share/vm/code/dependencies.cpp

Changeset: 9024b6b53ec2
Author:    vlivanov
Date:      2012-10-05 19:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9024b6b53ec2

8000485: Hotspot build fails in Solaris Studio IDE when building dtrace
Summary: Prepend '.' to the existing native library path
Reviewed-by: kvn, sspitsyn

! make/bsd/makefiles/dtrace.make
! make/solaris/makefiles/dtrace.make

Changeset: 377508648226
Author:    vlivanov
Date:      2012-10-08 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/377508648226

8000313: C2 should use jlong for 64bit values
Summary: Replace all occurrences of long with jlong in C2 code.
Reviewed-by: kvn, twisti

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

Changeset: 65d07d9ee446
Author:    twisti
Date:      2012-10-08 17:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/65d07d9ee446

8000263: JSR 292: signature types may appear to be unloaded
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 8e47bac5643a
Author:    roland
Date:      2012-10-09 10:11 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8e47bac5643a

7054512: Compress class pointers after perm gen removal
Summary: support of compress class pointers in the compilers.
Reviewed-by: kvn, twisti

! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/NarrowKlassField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java
! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java
! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/dtrace/generateJvmOffsets.cpp
! src/os/bsd/dtrace/jhelper.d
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/jhelper.d
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/instanceOop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: f6badecb7ea7
Author:    vlivanov
Date:      2012-10-09 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f6badecb7ea7

7199654: Remove LoadUI2LNode
Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead.
Reviewed-by: kvn

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/superword.cpp

Changeset: d336b3173277
Author:    kvn
Date:      2012-10-09 16:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d336b3173277

8000592: Improve adlc usability
Summary: several changes to adlc to improve its usability
Reviewed-by: kvn
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/archDesc.hpp
! src/share/vm/adlc/dict2.cpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/main.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: 94e9408dbf50
Author:    roland
Date:      2012-10-11 18:21 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/94e9408dbf50

8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off
Summary: code generated by c1 for getClass intrinsic broken when klass field is loaded on 64bit with compressed klass off.
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp

Changeset: 19eb999cb72c
Author:    twisti
Date:      2012-10-11 14:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/19eb999cb72c

8000740: remove LinkWellKnownClasses
Reviewed-by: kvn, jrose

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

Changeset: d804e148cff8
Author:    kvn
Date:      2012-10-12 09:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d804e148cff8

Merge

! make/bsd/makefiles/dtrace.make
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/vmStructs.cpp


From gary.collins at oracle.com  Fri Oct 12 13:46:34 2012
From: gary.collins at oracle.com (gary.collins at oracle.com)
Date: Fri, 12 Oct 2012 20:46:34 +0000
Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets
Message-ID: <20121012204644.C539F47335@hg.openjdk.java.net>

Changeset: fb19af007ffc
Author:    jprovino
Date:      2012-10-10 14:35 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fb19af007ffc

7189254: Change makefiles for more flexibility to override defaults
Summary: Change makefiles so that targets and parameters can be overridden by alternate makefiles.
Reviewed-by: dholmes, coleenp

! make/Makefile
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/ia64.make
+ make/bsd/makefiles/minimal1.make
! make/bsd/makefiles/vm.make
! make/defs.make
+ make/excludeSrc.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/ia64.make
+ make/linux/makefiles/minimal1.make
! make/linux/makefiles/vm.make
! make/windows/makefiles/defs.make
! src/os/solaris/vm/os_solaris.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/metaspaceShared.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/forte.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/prims/jvmtiEnvBase.hpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/prims/jvmtiThreadState.hpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/fprofiler.hpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/classLoadingService.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/services/heapDumper.hpp
! src/share/vm/services/management.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/services/runtimeService.cpp
! src/share/vm/services/runtimeService.hpp
! src/share/vm/utilities/macros.hpp

Changeset: bbeecede56dd
Author:    jiangli
Date:      2012-10-11 14:36 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bbeecede56dd

8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests.
Summary: Remove unneeded assert.
Reviewed-by: sspitsyn, coleenp

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

Changeset: 9855b7e559ae
Author:    collins
Date:      2012-10-12 10:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9855b7e559ae

Merge

! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/gcc.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/vm.make
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/management.cpp

Changeset: 5876f980ea19
Author:    collins
Date:      2012-10-12 11:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5876f980ea19

Merge

! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp


From vladimir.x.ivanov at oracle.com  Fri Oct 12 13:56:43 2012
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 13 Oct 2012 00:56:43 +0400
Subject: Why MACOSX_UNIVERSAL == true by default?
Message-ID: <5078840B.2070005@oracle.com>

Hi,

Does anybody know/remember why MACOSX_UNIVERSAL=true by default?

I'm asking, because JDK layout on MacOS X differs from other platforms 
and to make export_*_jdk build targets work correctly, you need to 
specify ALT_MACOSX_UNIVERSAL=false.

I'd like to fix that (change default value to false), but I have no idea 
why it was set to true in the first place.

Best regards,
Vladimir Ivanov

From scott.kovatch at oracle.com  Fri Oct 12 14:12:30 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Fri, 12 Oct 2012 14:12:30 -0700
Subject: Why MACOSX_UNIVERSAL == true by default?
In-Reply-To: <5078840B.2070005@oracle.com>
References: <5078840B.2070005@oracle.com>
Message-ID: <9748987F-65CA-4E7B-8DB8-B1CC169E0418@oracle.com>

On Oct 12, 2012, at 1:56 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Hi,
> 
> Does anybody know/remember why MACOSX_UNIVERSAL=true by default?
> 
> I'm asking, because JDK layout on MacOS X differs from other platforms and to make export_*_jdk build targets work correctly, you need to specify ALT_MACOSX_UNIVERSAL=false.
> 
> I'd like to fix that (change default value to false), but I have no idea why it was set to true in the first place.

When the Mac port of JDK 7 was in its own project it was being built universal (i.e., both 32- and 64-bit executables in the same binary). As a result, there's never been a reason to separate out each binary by architecture as is done on other platforms.

When that project was merged over to the main JDK 7 project, though, we stopped building the 32-bit version. I suspect, however, that that flag also tells the build to not create the per-architecture directories because so much code in the native support on OS X assumes that libjvm.dylib won't be in a subfolder.

-- Scott K.

----------------------------------------
Scott Kovatch
scott.kovatch at oracle.com
Santa Clara/Pleasanton, CA



From daniel.daugherty at oracle.com  Fri Oct 12 14:21:37 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 12 Oct 2012 15:21:37 -0600
Subject: Why MACOSX_UNIVERSAL == true by default?
In-Reply-To: <5078840B.2070005@oracle.com>
References: <5078840B.2070005@oracle.com>
Message-ID: <507889E1.1090707@oracle.com>

Adding macosx-port-dev at ... to the thread...


On 10/12/12 2:56 PM, Vladimir Ivanov wrote:
> Hi,
>
> Does anybody know/remember why MACOSX_UNIVERSAL=true by default?

Yes. :-)


> I'm asking, because JDK layout on MacOS X differs from other platforms 
> and to make export_*_jdk build targets work correctly, you need to 
> specify ALT_MACOSX_UNIVERSAL=false.
>
> I'd like to fix that (change default value to false), but I have no 
> idea why it was set to true in the first place.

Jim Melvin restored Universal build support into HotSpot. However,
the rest of the JDK did not follow suit. As far as I know/remember,
only the hotspot repo supports Universal build at the moment.

Dan

>
> Best regards,
> Vladimir Ivanov

From david.holmes at oracle.com  Fri Oct 12 15:39:57 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 13 Oct 2012 08:39:57 +1000
Subject: Why MACOSX_UNIVERSAL == true by default?
In-Reply-To: <507889E1.1090707@oracle.com>
References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com>
Message-ID: <50789C3D.90302@oracle.com>

Also see:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-January/005153.html

re Jim's updates.

David

On 13/10/2012 7:21 AM, Daniel D. Daugherty wrote:
> Adding macosx-port-dev at ... to the thread...
>
>
> On 10/12/12 2:56 PM, Vladimir Ivanov wrote:
>> Hi,
>>
>> Does anybody know/remember why MACOSX_UNIVERSAL=true by default?
>
> Yes. :-)
>
>
>> I'm asking, because JDK layout on MacOS X differs from other platforms
>> and to make export_*_jdk build targets work correctly, you need to
>> specify ALT_MACOSX_UNIVERSAL=false.
>>
>> I'd like to fix that (change default value to false), but I have no
>> idea why it was set to true in the first place.
>
> Jim Melvin restored Universal build support into HotSpot. However,
> the rest of the JDK did not follow suit. As far as I know/remember,
> only the hotspot repo supports Universal build at the moment.
>
> Dan
>
>>
>> Best regards,
>> Vladimir Ivanov

From alejandro.murillo at oracle.com  Fri Oct 12 16:13:48 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 12 Oct 2012 23:13:48 +0000
Subject: hg: hsx/hsx25/hotspot: 31 new changesets
Message-ID: <20121012231451.91B484734B@hg.openjdk.java.net>

Changeset: 0cc77f9b31ad
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0cc77f9b31ad

Added tag jdk8-b60 for changeset 3cfd05b2219a

! .hgtags

Changeset: 81e878c53615
Author:    amurillo
Date:      2012-10-05 13:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/81e878c53615

8000498: new hotspot build - hs25-b05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: d8ce2825b193
Author:    coleenp
Date:      2012-09-29 06:40 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d8ce2825b193

8000213: NPG: Should have renamed arrayKlass and typeArrayKlass
Summary: Capitalize these metadata types (and objArrayKlass)
Reviewed-by: stefank, twisti, kvn

! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciArrayKlass.cpp
! src/share/vm/ci/ciArrayKlass.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciKlass.hpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciObjArrayKlass.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciTypeArrayKlass.cpp
! src/share/vm/ci/ciTypeArrayKlass.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/memory/specialized_oop_closures.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/oops/objArrayKlass.inline.hpp
! src/share/vm/oops/objArrayOop.cpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/oops/oop.pcgc.inline.hpp
! src/share/vm/oops/oop.psgc.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.hpp
! src/share/vm/oops/typeArrayOop.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/threadService.cpp
! src/share/vm/shark/sharkRuntime.cpp

Changeset: fab6fbf427d2
Author:    kevinw
Date:      2012-09-30 23:24 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fab6fbf427d2

7200145: runtime/7196045/Test7196045.java fails with No class provided for `main'
Reviewed-by: dholmes, dsamersoff

! test/runtime/7196045/Test7196045.java

Changeset: ba8fd2fe198b
Author:    coleenp
Date:      2012-10-04 08:38 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ba8fd2fe198b

7198519: Broken build, hotspot-rt win USE_PRECOMPILED_HEADER=0
Summary: Uncommented out include for sys/stat.h and deleted include statements that were commented out.
Reviewed-by: coleenp, acorn, dholmes
Contributed-by: harold.seigel at oracle.com

! src/os/windows/vm/jvm_windows.h

Changeset: bacdc1d5c21c
Author:    coleenp
Date:      2012-10-04 08:43 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bacdc1d5c21c

6884973: java -XX:Atomics=2 crashes
Summary: Remove buggy experimental option
Reviewed-by: acorn, coleenp
Contributed-by: harold.seigel at oracle.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 48087f745a86
Author:    dholmes
Date:      2012-10-04 19:52 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/48087f745a86

7199186: runtime/7194254/Test7194254.java fails - wrong test name on @run
Reviewed-by: kvn, twisti

! test/runtime/7194254/Test7194254.java

Changeset: f2eb2d4488db
Author:    dholmes
Date:      2012-10-04 20:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f2eb2d4488db

Merge


Changeset: 75982791ddb6
Author:    coleenp
Date:      2012-10-08 09:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/75982791ddb6

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: 7a40901e0d5c
Author:    minqi
Date:      2012-10-08 16:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7a40901e0d5c

8000332: SA ClassDump throws exception after permgen removal
Summary: In ClassWrite.writeFields(), fields count was mistakenly set to fields length which overflow the array index. Also removed a file which is leftover from 6879063 changeset.
Reviewed-by: coleenp, sspitsyn
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/native/sadis.c

Changeset: 0e8ca886e4e1
Author:    minqi
Date:      2012-10-08 16:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0e8ca886e4e1

Merge


Changeset: 6e5a59a8e4a7
Author:    rbackman
Date:      2012-10-09 07:41 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6e5a59a8e4a7

Merge

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 26351ce8c4b0
Author:    coleenp
Date:      2012-10-09 02:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/26351ce8c4b0

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

Changeset: b9a9ed0f8eeb
Author:    mikael
Date:      2012-10-09 10:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b9a9ed0f8eeb

7197424: update copyright year to match last edit in jdk8 hotspot repository
Summary: Update copyright year to 2012 for relevant files
Reviewed-by: dholmes, coleenp

! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java
! agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java
! make/bsd/Makefile
! make/bsd/makefiles/adlc.make
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/dtrace.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/jvmg.make
! make/bsd/makefiles/launcher.make
! make/bsd/makefiles/product.make
! make/bsd/makefiles/rules.make
! make/bsd/makefiles/sparcWorks.make
! make/bsd/makefiles/top.make
! make/linux/makefiles/launcher.make
! make/linux/makefiles/ppc.make
! make/linux/makefiles/product.make
! make/linux/makefiles/rules.make
! make/linux/makefiles/sparcWorks.make
! make/linux/makefiles/top.make
! make/solaris/makefiles/adlc.make
! make/solaris/makefiles/gcc.make
! make/solaris/makefiles/jvmg.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/rules.make
! make/solaris/makefiles/top.make
! make/windows/build.bat
! make/windows/build_vm_def.sh
! make/windows/get_msc_ver.sh
! make/windows/makefiles/adlc.make
! make/windows/makefiles/launcher.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/rules.make
! make/windows/makefiles/sanity.make
! make/windows/makefiles/shared.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/common/Makefile
! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/x86/vm/c1_FrameMap_x86.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/cpu/x86/vm/templateTable_x86_32.hpp
! src/cpu/x86/vm/templateTable_x86_64.hpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/zero/vm/interpreterGenerator_zero.hpp
! src/cpu/zero/vm/methodHandles_zero.hpp
! src/os/bsd/vm/decoder_machO.cpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/decoder_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/posix/launcher/java_md.c
! src/os/posix/launcher/launcher.script
! src/os/posix/vm/os_posix.cpp
! src/os/posix/vm/os_posix.hpp
! src/os/solaris/dtrace/hs_private.d
! src/os/solaris/vm/attachListener_solaris.cpp
! src/os/solaris/vm/decoder_solaris.cpp
! src/os/solaris/vm/os_solaris.hpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/decoder_windows.hpp
! src/os/windows/vm/os_windows.hpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.hpp
! src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/solaris_x86_32.il
! src/os_cpu/solaris_x86/vm/solaris_x86_64.il
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/Util.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/register.hpp
! src/share/vm/c1/c1_CFGPrinter.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_LinearScan.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_ValueMap.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/c1/c1_ValueStack.cpp
! src/share/vm/c1/c1_ValueStack.hpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/ci/ciSymbol.cpp
! src/share/vm/ci/ciTypeFlow.hpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/javaAssertions.hpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/stubs.hpp
! src/share/vm/code/vmreg.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp
! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp
! src/share/vm/gc_implementation/g1/survRateGroup.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp
! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp
! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/shared/allocationStats.hpp
! src/share/vm/gc_implementation/shared/collectorCounters.cpp
! src/share/vm/gc_implementation/shared/collectorCounters.hpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp
! src/share/vm/gc_implementation/shared/gcStats.hpp
! src/share/vm/gc_implementation/shared/gcUtil.cpp
! src/share/vm/gc_implementation/shared/gcUtil.hpp
! src/share/vm/gc_implementation/shared/generationCounters.cpp
! src/share/vm/gc_implementation/shared/generationCounters.hpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/spaceCounters.cpp
! src/share/vm/gc_implementation/shared/spaceCounters.hpp
! src/share/vm/gc_implementation/shared/spaceDecorator.hpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/libadt/set.cpp
! src/share/vm/libadt/vectset.cpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/freeList.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/heap.hpp
! src/share/vm/memory/referencePolicy.hpp
! src/share/vm/memory/space.inline.hpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/divnode.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/prims/jniExport.hpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/prims/jvmtiExtensions.cpp
! src/share/vm/prims/jvmtiRawMonitor.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/prims/jvmtiUtil.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/dtraceJSDT.hpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/monitorChunk.cpp
! src/share/vm/runtime/monitorChunk.hpp
! src/share/vm/runtime/mutex.hpp
! src/share/vm/runtime/park.cpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/task.hpp
! src/share/vm/runtime/timer.cpp
! src/share/vm/runtime/vmThread.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/g1MemoryPool.cpp
! src/share/vm/services/g1MemoryPool.hpp
! src/share/vm/services/lowMemoryDetector.hpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/trace/tracing.hpp
! src/share/vm/utilities/array.cpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder_elf.cpp
! src/share/vm/utilities/elfFile.cpp
! src/share/vm/utilities/elfFile.hpp
! src/share/vm/utilities/elfStringTable.cpp
! src/share/vm/utilities/elfStringTable.hpp
! src/share/vm/utilities/elfSymbolTable.cpp
! src/share/vm/utilities/elfSymbolTable.hpp
! src/share/vm/utilities/globalDefinitions_visCPP.hpp
! src/share/vm/utilities/growableArray.cpp
! src/share/vm/utilities/histogram.cpp
! src/share/vm/utilities/histogram.hpp
! src/share/vm/utilities/intHisto.cpp
! src/share/vm/utilities/intHisto.hpp
! src/share/vm/utilities/preserveException.cpp
! src/share/vm/utilities/stack.hpp
! src/share/vm/utilities/stack.inline.hpp
! src/share/vm/utilities/taskqueue.hpp
! src/share/vm/utilities/vmError.hpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp
! test/compiler/6859338/Test6859338.java
! test/compiler/7116216/StackOverflow.java

Changeset: c3e799c37717
Author:    vlivanov
Date:      2012-10-05 18:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c3e799c37717

7177003: C1: LogCompilation support
Summary: add LogCompilation support in C1 - both client and tiered mode.
Reviewed-by: twisti, kvn

! src/os/linux/vm/vmError_linux.cpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compileLog.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/ostream.cpp

Changeset: 9a9b6e05ffb4
Author:    vlivanov
Date:      2012-10-05 19:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9a9b6e05ffb4

8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64
Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore.
Reviewed-by: twisti, kvn

! src/share/vm/code/dependencies.cpp

Changeset: 9024b6b53ec2
Author:    vlivanov
Date:      2012-10-05 19:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9024b6b53ec2

8000485: Hotspot build fails in Solaris Studio IDE when building dtrace
Summary: Prepend '.' to the existing native library path
Reviewed-by: kvn, sspitsyn

! make/bsd/makefiles/dtrace.make
! make/solaris/makefiles/dtrace.make

Changeset: 377508648226
Author:    vlivanov
Date:      2012-10-08 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/377508648226

8000313: C2 should use jlong for 64bit values
Summary: Replace all occurrences of long with jlong in C2 code.
Reviewed-by: kvn, twisti

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

Changeset: 65d07d9ee446
Author:    twisti
Date:      2012-10-08 17:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/65d07d9ee446

8000263: JSR 292: signature types may appear to be unloaded
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 8e47bac5643a
Author:    roland
Date:      2012-10-09 10:11 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8e47bac5643a

7054512: Compress class pointers after perm gen removal
Summary: support of compress class pointers in the compilers.
Reviewed-by: kvn, twisti

! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/NarrowKlassField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java
! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java
! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/dtrace/generateJvmOffsets.cpp
! src/os/bsd/dtrace/jhelper.d
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/jhelper.d
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/instanceOop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: f6badecb7ea7
Author:    vlivanov
Date:      2012-10-09 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f6badecb7ea7

7199654: Remove LoadUI2LNode
Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead.
Reviewed-by: kvn

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/superword.cpp

Changeset: d336b3173277
Author:    kvn
Date:      2012-10-09 16:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d336b3173277

8000592: Improve adlc usability
Summary: several changes to adlc to improve its usability
Reviewed-by: kvn
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/archDesc.hpp
! src/share/vm/adlc/dict2.cpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/main.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: 94e9408dbf50
Author:    roland
Date:      2012-10-11 18:21 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/94e9408dbf50

8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off
Summary: code generated by c1 for getClass intrinsic broken when klass field is loaded on 64bit with compressed klass off.
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp

Changeset: 19eb999cb72c
Author:    twisti
Date:      2012-10-11 14:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/19eb999cb72c

8000740: remove LinkWellKnownClasses
Reviewed-by: kvn, jrose

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

Changeset: d804e148cff8
Author:    kvn
Date:      2012-10-12 09:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d804e148cff8

Merge

! make/bsd/makefiles/dtrace.make
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: fb19af007ffc
Author:    jprovino
Date:      2012-10-10 14:35 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fb19af007ffc

7189254: Change makefiles for more flexibility to override defaults
Summary: Change makefiles so that targets and parameters can be overridden by alternate makefiles.
Reviewed-by: dholmes, coleenp

! make/Makefile
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/ia64.make
+ make/bsd/makefiles/minimal1.make
! make/bsd/makefiles/vm.make
! make/defs.make
+ make/excludeSrc.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/ia64.make
+ make/linux/makefiles/minimal1.make
! make/linux/makefiles/vm.make
! make/windows/makefiles/defs.make
! src/os/solaris/vm/os_solaris.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/metaspaceShared.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/forte.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/prims/jvmtiEnvBase.hpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/prims/jvmtiThreadState.hpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/fprofiler.hpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/classLoadingService.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/services/heapDumper.hpp
! src/share/vm/services/management.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/services/runtimeService.cpp
! src/share/vm/services/runtimeService.hpp
! src/share/vm/utilities/macros.hpp

Changeset: bbeecede56dd
Author:    jiangli
Date:      2012-10-11 14:36 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bbeecede56dd

8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests.
Summary: Remove unneeded assert.
Reviewed-by: sspitsyn, coleenp

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

Changeset: 9855b7e559ae
Author:    collins
Date:      2012-10-12 10:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9855b7e559ae

Merge

! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/gcc.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/vm.make
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/management.cpp

Changeset: 5876f980ea19
Author:    collins
Date:      2012-10-12 11:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5876f980ea19

Merge

! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: b261523fe66c
Author:    amurillo
Date:      2012-10-12 13:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b261523fe66c

Merge


Changeset: 4547dc71db76
Author:    amurillo
Date:      2012-10-12 13:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4547dc71db76

Added tag hs25-b05 for changeset b261523fe66c

! .hgtags


From john.cuthbertson at oracle.com  Fri Oct 12 16:17:32 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 12 Oct 2012 16:17:32 -0700
Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete
Message-ID: <5078A50C.6050508@oracle.com>

Hi Everyone,

Can I have a couple of volunteers review the fix for this CR - the 
webrev can be found at: http://cr.openjdk.java.net/~johnc/8000831/webrev.0/

Summary:
An earlier change inadvertently turned off part of the output of heap 
verification:

[Verifying threads syms strs zone dict hand C-heap code cache ]
 VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)] 
16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00, 
real=0.02 secs]
 VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)] 
17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00, 
real=0.01 secs]
 VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)] 
17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03, 
real=0.06 secs]
 VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)] 
17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00, 
real=0.02 secs]
 VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)] 
34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04, 
real=0.09 secs]
 VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)] 
35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00, 
real=0.03 secs]
 VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)] 
69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11, 
real=0.20 secs]

Previously it was:

[Verifying threads syms strs zone dict hand C-heap code cache ]
 VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone 
dict hand C-heap code cache ]
4.818: [GC [PSYoungGen: 16896K->392K(19712K)] 16896K->396K(62720K), 
0.0244147 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
 VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone 
dict hand C-heap code cache ]
5.087: [GC [PSYoungGen: 17288K->392K(19712K)] 17292K->400K(62720K), 
0.0597174 secs] [Times: user=0.04 sys=0.03, real=0.06 secs]
 VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone 
dict hand C-heap code cache ]
5.410: [GC [PSYoungGen: 17288K->400K(19712K)] 17296K->412K(62720K), 
0.0173056 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
 VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone 
dict hand C-heap code cache ]
5.595: [GC [PSYoungGen: 17296K->400K(36608K)] 17308K->416K(79616K), 
0.0134239 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

The changes restore the previous output for the affected collectors.

Testing:
GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with serial, 
parallel, concurrent, and G1 collectors.

Thanks,

JohnC


From john.cuthbertson at oracle.com  Fri Oct 12 16:21:13 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 12 Oct 2012 16:21:13 -0700
Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete
In-Reply-To: <5078A50C.6050508@oracle.com>
References: <5078A50C.6050508@oracle.com>
Message-ID: <5078A5E9.3000901@oracle.com>

Hi Everyone,

Please disregard the previous email. I meant to send it to the 
hotspot-gc-dev mailing list. Although, you're more than welcome to 
review the change.

Apologies,

JohnC

On 10/12/12 16:17, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review the fix for this CR - the 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/8000831/webrev.0/
>
> Summary:
> An earlier change inadvertently turned off part of the output of heap 
> verification:
>
> [Verifying threads syms strs zone dict hand C-heap code cache ]
> VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)] 
> 16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00, 
> real=0.02 secs]
> VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)] 
> 17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00, 
> real=0.01 secs]
> VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)] 
> 17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03, 
> real=0.06 secs]
> VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)] 
> 17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00, 
> real=0.02 secs]
> VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)] 
> 34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04, 
> real=0.09 secs]
> VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)] 
> 35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00, 
> real=0.03 secs]
> VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)] 
> 69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11, 
> real=0.20 secs]
>
> Previously it was:
>
> [Verifying threads syms strs zone dict hand C-heap code cache ]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs 
> zone dict hand C-heap code cache ]
> 4.818: [GC [PSYoungGen: 16896K->392K(19712K)] 16896K->396K(62720K), 
> 0.0244147 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs 
> zone dict hand C-heap code cache ]
> 5.087: [GC [PSYoungGen: 17288K->392K(19712K)] 17292K->400K(62720K), 
> 0.0597174 secs] [Times: user=0.04 sys=0.03, real=0.06 secs]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs 
> zone dict hand C-heap code cache ]
> 5.410: [GC [PSYoungGen: 17288K->400K(19712K)] 17296K->412K(62720K), 
> 0.0173056 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs 
> zone dict hand C-heap code cache ]
> 5.595: [GC [PSYoungGen: 17296K->400K(36608K)] 17308K->416K(79616K), 
> 0.0134239 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
>
> The changes restore the previous output for the affected collectors.
>
> Testing:
> GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with 
> serial, parallel, concurrent, and G1 collectors.
>
> Thanks,
>
> JohnC
>


From alejandro.murillo at oracle.com  Fri Oct 12 18:03:31 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 13 Oct 2012 01:03:31 +0000
Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets
Message-ID: <20121013010340.DFE7A4734F@hg.openjdk.java.net>

Changeset: 0cc77f9b31ad
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0cc77f9b31ad

Added tag jdk8-b60 for changeset 3cfd05b2219a

! .hgtags

Changeset: b261523fe66c
Author:    amurillo
Date:      2012-10-12 13:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b261523fe66c

Merge


Changeset: 4547dc71db76
Author:    amurillo
Date:      2012-10-12 13:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4547dc71db76

Added tag hs25-b05 for changeset b261523fe66c

! .hgtags

Changeset: 58fbf2da3c16
Author:    amurillo
Date:      2012-10-12 14:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/58fbf2da3c16

8000834: new hotspot build - hs25-b06
Reviewed-by: jcoomes

! make/hotspot_version


From marco.dinacci at gmail.com  Sat Oct 13 01:29:22 2012
From: marco.dinacci at gmail.com (Marco Dinacci)
Date: Sat, 13 Oct 2012 09:29:22 +0100
Subject: Why MACOSX_UNIVERSAL == true by default?
In-Reply-To: <CALyUpY2rT0w5CCx96PFuhPxt8scL2ddVEKuJoVm0FK8SkoEhig@mail.gmail.com>
References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com>
	<CALyUpY2rT0w5CCx96PFuhPxt8scL2ddVEKuJoVm0FK8SkoEhig@mail.gmail.com>
Message-ID: <CAC8dNtDS-SeGW8v4eNwbg1K-Ja1OwGvaqaA+x3oCCX-F_mSe=w@mail.gmail.com>

Hi,

> Sadly I still get errors with Jenkins (test app) when using -d32.
> Anyboby willing to take a look in it ?
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x00e54875, pid=15221, tid=5891
> #
> # JRE version: 7.0
> # Java VM: OpenJDK Server VM (23.6-b03 mixed mode bsd-x86 )
> # Problematic frame:
> # J  sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;
> #

I encountered the same issue on OSX Leopard with a JDK7u compiled with
Henry's universal patch.
For the moment I use this workaround:

-XX:CompileCommand=exclude,sun/nio/cs/StreamDecoder,read

However after solving this crash another follows (sorry can't remember
the details now), which I prevent using:

-XX:-UseLoopPredicate -XX:-LoopLimitCheck


Best,
Marco

From marco.dinacci at gmail.com  Sat Oct 13 04:59:26 2012
From: marco.dinacci at gmail.com (Marco Dinacci)
Date: Sat, 13 Oct 2012 12:59:26 +0100
Subject: Why MACOSX_UNIVERSAL == true by default?
In-Reply-To: <CALyUpY2NbVvPj0614vUF+dRtE+GhnvrEvxassw+ikpnpHc0QTA@mail.gmail.com>
References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com>
	<CALyUpY2rT0w5CCx96PFuhPxt8scL2ddVEKuJoVm0FK8SkoEhig@mail.gmail.com>
	<CAC8dNtDS-SeGW8v4eNwbg1K-Ja1OwGvaqaA+x3oCCX-F_mSe=w@mail.gmail.com>
	<CALyUpY2NbVvPj0614vUF+dRtE+GhnvrEvxassw+ikpnpHc0QTA@mail.gmail.com>
Message-ID: <CAC8dNtAUXALmgh=UnDipa0TOmLqyqjxFY76Ocj0uFyeA99sQXA@mail.gmail.com>

Hi,

> Marco, you're using openjdk-build-project packages on Leopard (10.5) ?
> And in 32bits mode (-d32) ?

Sorry I meant *Snow* Leopard (10.6).
I use my own package to which I added your universal build patch, I
didn't specifically launch the JVM in 32bits mode but I experienced
exactly the same crash you reported when testing on 10.6.6 64bits. It
happens systematically because every user we have using Snow Leopard
has the same crash. Adding the options I wrote in the previous post
"fixes" it.

Best,
Marco

From david.holmes at oracle.com  Sun Oct 14 16:10:16 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 09:10:16 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
Message-ID: <507B4658.5090401@oracle.com>

On 13/10/2012 1:40 AM, Nils Loodin wrote:
> So in general we have two competing wishes here:
>
> 1. Use std::nothrow, in operator new() and enum in the allocation methods. (basically webrev 03)
> Pros: more c++ standard-ish
> cons: more boiler plate, not descriptive of what actually happens, two different mechanisms.
>
>
> 2. Use enums everywhere (basically a bugfree version of 04):
> pros: more accurate description, cleaner implementation
> cons: it's an instance of "not invented here"-syndrom, ie, we're making up our own stuff.

I'm less supportive of using an Enum over a boolean now. A two-valued 
enum is a boolean. And we are treating it as a boolean any time we use 
if-else rather than a switch-style selector - we couldn't add a third 
option without revisiting every place it is currently checked. And I 
just don't see there being any third option.

I never liked std::nothrow because we never threw in the first place, 
but if it had instead been std::return_null I would have been fine with 
it. But given we use custom multi-arg variants of operator new I don't 
see that the "familiarity"/"standard" argument really has that much 
weight. If anything using a standard feature in a non-standard 
environment is likely to be more confusing to people who might naturally 
expect that if they see a no_throw variant then the other variant will 
in fact throw, not abort the VM!

I have some specific comments on specific changes but there doesn't seem 
much point going to that level of discussion yet. Except I will mention 
that in thread.cpp the pre-existing throw_excpt argument to allocate 
seems to really mean "exit_out_of_memory" and should be renamed.

David
-----

> So.. discuss! John, what do you think having seen the different implementations? It would be nice to be able to get in any version of it so I can develop the feature that will depend on it... :)
>
> Regards,
> Nisse
>
> On Oct 12, 2012, at 17:03 , Coleen Phillimore<coleen.phillimore at oracle.com>  wrote:
>
>>
>> I still prefer webrev 03 to webrev 04.   std::nothrow as a parameter means something to any C++ developer and AllocationStrategy::OOM only means something to a hotspot developer.  I think we should use the standard C++ apis when possible.  The duplication of operator new is not significant.   Plus if someone adds new (std::nothrow) call or you forgot to clean up one, it think it will overload to the std::operator new() which could lead to a subtle bug.
>>
>> Coleen
>>
>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>
>>>
>>>
>>> 12 okt 2012 kl. 16:25 skrev Keith McGuigan<keith.mcguigan at oracle.com>:
>>>
>>>> May as well lift the allocation fail strategy up into Thread::allocate() as well, replacing the boolean parameter there.
>>>>
>>> Ah, good idea.
>>>
>>>> I think you're replacements of new(std::nothrow) XXX() wit new (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to replace it with RETURN_NULL.
>>>>
>>>> -
>>> Argh, darn, you're right of course.
>>>
>>> Will fix.
>>>
>>>> - Keith
>>>>
>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>
>>>>> Hey guys!
>>>>>
>>>>> Thanks for yet another round of informative code reviews!
>>>>> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
>>>>>
>>>>> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
>>>>>
>>>>> What do you think now?
>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>
>>>>> Have a nice weekend!
>>>>>
>>>>> Regards,
>>>>> Nils Loodin
>>>>>
>>>>>
>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>> Hi Nils,
>>>>>>>
>>>>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>>>>> needed yet another.
>>>>>>>
>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>> Hey guys.
>>>>>>>>
>>>>>>>> Your comments on this issue are great! So here's another version that
>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>>>>> Apologies it wasn't NMT that introduced this - it is a bit older than
>>>>>> that: April 2011. See
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>
>>>>>> and some comments in
>>>>>>
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>
>>>>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>>>>> anything related to the exception mechanism, which we don't use at all.
>>>>>>
>>>>>>> any exceptions involved!) but introducing a completely different
>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>>>>>> approach but would like to see this solved holistically, replacing
>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>>>>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>>>>>> just another point-patch put in place.
>>>>>> The bigger problem is probably still too big to really handle - so
>>>>>> either copy what we already introduced for CHeapObj to ResourceObj for
>>>>>> consistency, or replace both with something better.
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> For the record I found the original proposal extremely confusing:
>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>
>>>>>>> Sorry.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nils Loodin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>> Keith,
>>>>>>>>>
>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>>>>>
>>>>>>>>> -Dmitry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>>>>> forward
>>>>>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>>>>>
>>>>>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>>>>> present
>>>>>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>>>>>> add
>>>>>>>>>> a new value to use. However if this ends up being confusing because
>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>>>>>> something else.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> - Keith
>

From david.holmes at oracle.com  Sun Oct 14 16:16:00 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 09:16:00 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507B4658.5090401@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
	<507B4658.5090401@oracle.com>
Message-ID: <507B47B0.5000805@oracle.com>

PS. I should also add that if we were to fix this all properly then 
there would be no "alloc-fail-mode" flag and every allocation function 
would be capable of returning null - with the "top-level" deciding how 
the OOM condition should be handled. Ironically because we don't use C++ 
exceptions we have no way to communicate incidental allocation failures 
up the call chain, so we can't fix this properly without changing a lot 
of code (which is why it remains a long standing open RFE).

With all that said perhaps the way forward for Nils is to augment the 
ResourceArea allocation routines in exactly the same way as the CHeapObj 
allocation routines - minimal changes using std::no_throw, and perhaps 
keeping the no_throw=>os::malloc mapping?

David
-----

On 15/10/2012 9:10 AM, David Holmes wrote:
> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>> So in general we have two competing wishes here:
>>
>> 1. Use std::nothrow, in operator new() and enum in the allocation
>> methods. (basically webrev 03)
>> Pros: more c++ standard-ish
>> cons: more boiler plate, not descriptive of what actually happens, two
>> different mechanisms.
>>
>>
>> 2. Use enums everywhere (basically a bugfree version of 04):
>> pros: more accurate description, cleaner implementation
>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>> making up our own stuff.
>
> I'm less supportive of using an Enum over a boolean now. A two-valued
> enum is a boolean. And we are treating it as a boolean any time we use
> if-else rather than a switch-style selector - we couldn't add a third
> option without revisiting every place it is currently checked. And I
> just don't see there being any third option.
>
> I never liked std::nothrow because we never threw in the first place,
> but if it had instead been std::return_null I would have been fine with
> it. But given we use custom multi-arg variants of operator new I don't
> see that the "familiarity"/"standard" argument really has that much
> weight. If anything using a standard feature in a non-standard
> environment is likely to be more confusing to people who might naturally
> expect that if they see a no_throw variant then the other variant will
> in fact throw, not abort the VM!
>
> I have some specific comments on specific changes but there doesn't seem
> much point going to that level of discussion yet. Except I will mention
> that in thread.cpp the pre-existing throw_excpt argument to allocate
> seems to really mean "exit_out_of_memory" and should be renamed.
>
> David
> -----
>
>> So.. discuss! John, what do you think having seen the different
>> implementations? It would be nice to be able to get in any version of
>> it so I can develop the feature that will depend on it... :)
>>
>> Regards,
>> Nisse
>>
>> On Oct 12, 2012, at 17:03 , Coleen
>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>
>>>
>>> I still prefer webrev 03 to webrev 04. std::nothrow as a parameter
>>> means something to any C++ developer and AllocationStrategy::OOM only
>>> means something to a hotspot developer. I think we should use the
>>> standard C++ apis when possible. The duplication of operator new is
>>> not significant. Plus if someone adds new (std::nothrow) call or you
>>> forgot to clean up one, it think it will overload to the
>>> std::operator new() which could lead to a subtle bug.
>>>
>>> Coleen
>>>
>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>
>>>>
>>>>
>>>> 12 okt 2012 kl. 16:25 skrev Keith McGuigan<keith.mcguigan at oracle.com>:
>>>>
>>>>> May as well lift the allocation fail strategy up into
>>>>> Thread::allocate() as well, replacing the boolean parameter there.
>>>>>
>>>> Ah, good idea.
>>>>
>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to
>>>>> replace it with RETURN_NULL.
>>>>>
>>>>> -
>>>> Argh, darn, you're right of course.
>>>>
>>>> Will fix.
>>>>
>>>>> - Keith
>>>>>
>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>
>>>>>> Hey guys!
>>>>>>
>>>>>> Thanks for yet another round of informative code reviews!
>>>>>> So I got rid of all the instances of std::nothrow throughout the
>>>>>> code and replaced them with a new shiny and descriptive enum.
>>>>>>
>>>>>> Was able to fold together a few specialized operator new() because
>>>>>> of it, with more shared code as a result.
>>>>>>
>>>>>> What do you think now?
>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>
>>>>>> Have a nice weekend!
>>>>>>
>>>>>> Regards,
>>>>>> Nils Loodin
>>>>>>
>>>>>>
>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>> Hi Nils,
>>>>>>>>
>>>>>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>>>>>> needed yet another.
>>>>>>>>
>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>> Hey guys.
>>>>>>>>>
>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>> version that
>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>> aren't even
>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit older
>>>>>>> than
>>>>>>> that: April 2011. See
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>
>>>>>>> and some comments in
>>>>>>>
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>
>>>>>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>>>>>> anything related to the exception mechanism, which we don't use
>>>>>>> at all.
>>>>>>>
>>>>>>>> any exceptions involved!) but introducing a completely different
>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail
>>>>>>>> strategy"
>>>>>>>> approach but would like to see this solved holistically, replacing
>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>> handle all
>>>>>>>> OOM situations gracefully rather than just aborting, I'd rather
>>>>>>>> not see
>>>>>>>> just another point-patch put in place.
>>>>>>> The bigger problem is probably still too big to really handle - so
>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>> ResourceObj for
>>>>>>> consistency, or replace both with something better.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> For the record I found the original proposal extremely confusing:
>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>
>>>>>>>> Sorry.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Nils Loodin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>> Keith,
>>>>>>>>>>
>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...)
>>>>>>>>>> function.
>>>>>>>>>>
>>>>>>>>>> -Dmitry
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>> implemented,
>>>>>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>>>>>> forward
>>>>>>>>>>> and easily understandable by future generations of hotspot
>>>>>>>>>>> developers.
>>>>>>>>>>> With this in mind, the only potential solution that I don't
>>>>>>>>>>> like is
>>>>>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>>>>>>
>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural
>>>>>>>>>>> way to do
>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>>>>>> present
>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>> simple just
>>>>>>>>>>> add
>>>>>>>>>>> a new value to use. However if this ends up being confusing
>>>>>>>>>>> because
>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we
>>>>>>>>>>> can do
>>>>>>>>>>> something else.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> - Keith
>>

From ysr1729 at gmail.com  Sun Oct 14 23:06:41 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Sun, 14 Oct 2012 23:06:41 -0700
Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete
In-Reply-To: <5078A50C.6050508@oracle.com>
References: <5078A50C.6050508@oracle.com>
Message-ID: <CABzyjynSfKuPmtuhYmnARZY_eSYt1p=An_YE-2AC_B-4ofOvHw@mail.gmail.com>

Changes look fine. (I wonder though if there are any callers of the
"silent" verification option at all now.... Can't recall if the slinet mode
was ever used and if so when; and don't have the source code handy to check
right now.)

-- ramki

On Fri, Oct 12, 2012 at 4:17 PM, John Cuthbertson <
john.cuthbertson at oracle.com> wrote:

> Hi Everyone,
>
> Can I have a couple of volunteers review the fix for this CR - the webrev
> can be found at: http://cr.openjdk.java.net/~**johnc/8000831/webrev.0/<http://cr.openjdk.java.net/%7Ejohnc/8000831/webrev.0/>
>
> Summary:
> An earlier change inadvertently turned off part of the output of heap
> verification:
>
> [Verifying threads syms strs zone dict hand C-heap code cache ]
> VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)]
> 16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00, real=0.02
> secs]
> VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)]
> 17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00, real=0.01
> secs]
> VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)]
> 17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03, real=0.06
> secs]
> VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)]
> 17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00, real=0.02
> secs]
> VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)]
> 34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04, real=0.09
> secs]
> VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)]
> 35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00,
> real=0.03 secs]
> VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)]
> 69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11,
> real=0.20 secs]
>
> Previously it was:
>
> [Verifying threads syms strs zone dict hand C-heap code cache ]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone
> dict hand C-heap code cache ]
> 4.818: [GC [PSYoungGen: 16896K->392K(19712K)] 16896K->396K(62720K),
> 0.0244147 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone
> dict hand C-heap code cache ]
> 5.087: [GC [PSYoungGen: 17288K->392K(19712K)] 17292K->400K(62720K),
> 0.0597174 secs] [Times: user=0.04 sys=0.03, real=0.06 secs]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone
> dict hand C-heap code cache ]
> 5.410: [GC [PSYoungGen: 17288K->400K(19712K)] 17296K->412K(62720K),
> 0.0173056 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone
> dict hand C-heap code cache ]
> 5.595: [GC [PSYoungGen: 17296K->400K(36608K)] 17308K->416K(79616K),
> 0.0134239 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
>
> The changes restore the previous output for the affected collectors.
>
> Testing:
> GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with serial,
> parallel, concurrent, and G1 collectors.
>
> Thanks,
>
> JohnC
>
>

From nils.loodin at oracle.com  Sun Oct 14 23:29:24 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Mon, 15 Oct 2012 08:29:24 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507B4658.5090401@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
	<507B4658.5090401@oracle.com>
Message-ID: <B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>


On Oct 15, 2012, at 01:10 , David Holmes wrote:

> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>> So in general we have two competing wishes here:
>> 
>> 1. Use std::nothrow, in operator new() and enum in the allocation methods. (basically webrev 03)
>> Pros: more c++ standard-ish
>> cons: more boiler plate, not descriptive of what actually happens, two different mechanisms.
>> 
>> 
>> 2. Use enums everywhere (basically a bugfree version of 04):
>> pros: more accurate description, cleaner implementation
>> cons: it's an instance of "not invented here"-syndrom, ie, we're making up our own stuff.
> 
> I'm less supportive of using an Enum over a boolean now. A two-valued enum is a boolean. And we are treating it as a boolean any time we use if-else rather than a switch-style selector - we couldn't add a third option without revisiting every place it is currently checked. And I just don't see there being any third option.
> 
Remember that the point of not having a boolean wasn't to enable a potential third option, but to make callsites clearer.
Alloc(size, false) is less descriptive than Alloc(size, no_throw).




> I never liked std::nothrow because we never threw in the first place, but if it had instead been std::return_null I would have been fine with it. But given we use custom multi-arg variants of operator new I don't see that the "familiarity"/"standard" argument really has that much weight. If anything using a standard feature in a non-standard environment is likely to be more confusing to people who might naturally expect that if they see a no_throw variant then the other variant will in fact throw, not abort the VM!
> 
> I have some specific comments on specific changes but there doesn't seem much point going to that level of discussion yet. Except I will mention that in thread.cpp the pre-existing throw_excpt argument to allocate seems to really mean "exit_out_of_memory" and should be renamed.
> 
> David
> -----
> 
>> So.. discuss! John, what do you think having seen the different implementations? It would be nice to be able to get in any version of it so I can develop the feature that will depend on it... :)
>> 
>> Regards,
>> Nisse
>> 
>> On Oct 12, 2012, at 17:03 , Coleen Phillimore<coleen.phillimore at oracle.com>  wrote:
>> 
>>> 
>>> I still prefer webrev 03 to webrev 04.   std::nothrow as a parameter means something to any C++ developer and AllocationStrategy::OOM only means something to a hotspot developer.  I think we should use the standard C++ apis when possible.  The duplication of operator new is not significant.   Plus if someone adds new (std::nothrow) call or you forgot to clean up one, it think it will overload to the std::operator new() which could lead to a subtle bug.
>>> 
>>> Coleen
>>> 
>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>> 
>>>> 
>>>> 
>>>> 12 okt 2012 kl. 16:25 skrev Keith McGuigan<keith.mcguigan at oracle.com>:
>>>> 
>>>>> May as well lift the allocation fail strategy up into Thread::allocate() as well, replacing the boolean parameter there.
>>>>> 
>>>> Ah, good idea.
>>>> 
>>>>> I think you're replacements of new(std::nothrow) XXX() wit new (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to replace it with RETURN_NULL.
>>>>> 
>>>>> -
>>>> Argh, darn, you're right of course.
>>>> 
>>>> Will fix.
>>>> 
>>>>> - Keith
>>>>> 
>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>> 
>>>>>> Hey guys!
>>>>>> 
>>>>>> Thanks for yet another round of informative code reviews!
>>>>>> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
>>>>>> 
>>>>>> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
>>>>>> 
>>>>>> What do you think now?
>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>> 
>>>>>> Have a nice weekend!
>>>>>> 
>>>>>> Regards,
>>>>>> Nils Loodin
>>>>>> 
>>>>>> 
>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>> Hi Nils,
>>>>>>>> 
>>>>>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>>>>>> needed yet another.
>>>>>>>> 
>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>> Hey guys.
>>>>>>>>> 
>>>>>>>>> Your comments on this issue are great! So here's another version that
>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit older than
>>>>>>> that: April 2011. See
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>> 
>>>>>>> and some comments in
>>>>>>> 
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>> 
>>>>>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>>>>>> anything related to the exception mechanism, which we don't use at all.
>>>>>>> 
>>>>>>>> any exceptions involved!) but introducing a completely different
>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>>>>>>> approach but would like to see this solved holistically, replacing
>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>>>>>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>>>>>>> just another point-patch put in place.
>>>>>>> The bigger problem is probably still too big to really handle - so
>>>>>>> either copy what we already introduced for CHeapObj to ResourceObj for
>>>>>>> consistency, or replace both with something better.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> David
>>>>>>> -----
>>>>>>> 
>>>>>>>> For the record I found the original proposal extremely confusing:
>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>> 
>>>>>>>> Sorry.
>>>>>>>> 
>>>>>>>> David
>>>>>>>> -----
>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Nils Loodin
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>> Keith,
>>>>>>>>>> 
>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>>>>>> 
>>>>>>>>>> -Dmitry
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>>>>>> forward
>>>>>>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>>>>>> 
>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>>>>>> present
>>>>>>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>>>>>>> add
>>>>>>>>>>> a new value to use. However if this ends up being confusing because
>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>>>>>>> something else.
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> - Keith
>> 


From david.holmes at oracle.com  Sun Oct 14 23:49:14 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 16:49:14 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
	<507B4658.5090401@oracle.com>
	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
Message-ID: <507BB1EA.4040605@oracle.com>

On 15/10/2012 4:29 PM, Nils Loodin wrote:
>
> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>
>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>> So in general we have two competing wishes here:
>>>
>>> 1. Use std::nothrow, in operator new() and enum in the allocation methods. (basically webrev 03)
>>> Pros: more c++ standard-ish
>>> cons: more boiler plate, not descriptive of what actually happens, two different mechanisms.
>>>
>>>
>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>> pros: more accurate description, cleaner implementation
>>> cons: it's an instance of "not invented here"-syndrom, ie, we're making up our own stuff.
>>
>> I'm less supportive of using an Enum over a boolean now. A two-valued enum is a boolean. And we are treating it as a boolean any time we use if-else rather than a switch-style selector - we couldn't add a third option without revisiting every place it is currently checked. And I just don't see there being any third option.
>>
> Remember that the point of not having a boolean wasn't to enable a potential third option, but to make callsites clearer.
> Alloc(size, false) is less descriptive than Alloc(size, no_throw).

Okay, but a bool constant has the same properties (and is used elsewhere 
in the VM).

David
------

>
>
>
>> I never liked std::nothrow because we never threw in the first place, but if it had instead been std::return_null I would have been fine with it. But given we use custom multi-arg variants of operator new I don't see that the "familiarity"/"standard" argument really has that much weight. If anything using a standard feature in a non-standard environment is likely to be more confusing to people who might naturally expect that if they see a no_throw variant then the other variant will in fact throw, not abort the VM!
>>
>> I have some specific comments on specific changes but there doesn't seem much point going to that level of discussion yet. Except I will mention that in thread.cpp the pre-existing throw_excpt argument to allocate seems to really mean "exit_out_of_memory" and should be renamed.
>>
>> David
>> -----
>>
>>> So.. discuss! John, what do you think having seen the different implementations? It would be nice to be able to get in any version of it so I can develop the feature that will depend on it... :)
>>>
>>> Regards,
>>> Nisse
>>>
>>> On Oct 12, 2012, at 17:03 , Coleen Phillimore<coleen.phillimore at oracle.com>   wrote:
>>>
>>>>
>>>> I still prefer webrev 03 to webrev 04.   std::nothrow as a parameter means something to any C++ developer and AllocationStrategy::OOM only means something to a hotspot developer.  I think we should use the standard C++ apis when possible.  The duplication of operator new is not significant.   Plus if someone adds new (std::nothrow) call or you forgot to clean up one, it think it will overload to the std::operator new() which could lead to a subtle bug.
>>>>
>>>> Coleen
>>>>
>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>
>>>>>
>>>>>
>>>>> 12 okt 2012 kl. 16:25 skrev Keith McGuigan<keith.mcguigan at oracle.com>:
>>>>>
>>>>>> May as well lift the allocation fail strategy up into Thread::allocate() as well, replacing the boolean parameter there.
>>>>>>
>>>>> Ah, good idea.
>>>>>
>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to replace it with RETURN_NULL.
>>>>>>
>>>>>> -
>>>>> Argh, darn, you're right of course.
>>>>>
>>>>> Will fix.
>>>>>
>>>>>> - Keith
>>>>>>
>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>
>>>>>>> Hey guys!
>>>>>>>
>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>> So I got rid of all the instances of std::nothrow throughout the code and replaced them with a new shiny and descriptive enum.
>>>>>>>
>>>>>>> Was able to fold together a few specialized operator new() because of it, with more shared code as a result.
>>>>>>>
>>>>>>> What do you think now?
>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>
>>>>>>> Have a nice weekend!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nils Loodin
>>>>>>>
>>>>>>>
>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>> Hi Nils,
>>>>>>>>>
>>>>>>>>> There are a number of existing bugs/RFEs in this area - not sure we
>>>>>>>>> needed yet another.
>>>>>>>>>
>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>> Hey guys.
>>>>>>>>>>
>>>>>>>>>> Your comments on this issue are great! So here's another version that
>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there aren't even
>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit older than
>>>>>>>> that: April 2011. See
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>
>>>>>>>> and some comments in
>>>>>>>>
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>
>>>>>>>> Till then we had avoided any use of C++ std:: stuff - particularly
>>>>>>>> anything related to the exception mechanism, which we don't use at all.
>>>>>>>>
>>>>>>>>> any exceptions involved!) but introducing a completely different
>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail strategy"
>>>>>>>>> approach but would like to see this solved holistically, replacing
>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM handle all
>>>>>>>>> OOM situations gracefully rather than just aborting, I'd rather not see
>>>>>>>>> just another point-patch put in place.
>>>>>>>> The bigger problem is probably still too big to really handle - so
>>>>>>>> either copy what we already introduced for CHeapObj to ResourceObj for
>>>>>>>> consistency, or replace both with something better.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> For the record I found the original proposal extremely confusing:
>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>
>>>>>>>>> Sorry.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Nils Loodin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>> Keith,
>>>>>>>>>>>
>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>>>>>>>>>
>>>>>>>>>>> -Dmitry
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>> Personally, I don't have strong feelings on how this is implemented,
>>>>>>>>>>>> other than it should be done in a way that's maintainable going
>>>>>>>>>>>> forward
>>>>>>>>>>>> and easily understandable by future generations of hotspot developers.
>>>>>>>>>>>> With this in mind, the only potential solution that I don't like is
>>>>>>>>>>>> using a boolean with naked true/false values as discriminators.
>>>>>>>>>>>>
>>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is already
>>>>>>>>>>>> present
>>>>>>>>>>>> in the few places we're interested in, it seemed easy to simple just
>>>>>>>>>>>> add
>>>>>>>>>>>> a new value to use. However if this ends up being confusing because
>>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>>>>>>>>>> something else.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> - Keith
>>>
>

From keith.mcguigan at oracle.com  Mon Oct 15 04:31:51 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Mon, 15 Oct 2012 07:31:51 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507B4658.5090401@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
	<507B4658.5090401@oracle.com>
Message-ID: <7BC852ED-5DF2-4641-BBD6-457806D44127@oracle.com>


On Oct 14, 2012, at 7:10 PM, David Holmes wrote:

> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>> So in general we have two competing wishes here:
>> 
>> 1. Use std::nothrow, in operator new() and enum in the allocation methods. (basically webrev 03)
>> Pros: more c++ standard-ish
>> cons: more boiler plate, not descriptive of what actually happens, two different mechanisms.
>> 
>> 
>> 2. Use enums everywhere (basically a bugfree version of 04):
>> pros: more accurate description, cleaner implementation
>> cons: it's an instance of "not invented here"-syndrom, ie, we're making up our own stuff.
> 
> I'm less supportive of using an Enum over a boolean now. A two-valued enum is a boolean. 

I disagree.  A two-valued enum adds code readability to the code, though I'm sure the resulting machine code is the same.  I'd much rather see a self-describing name at the callsite than a naked 'true' or 'false which requires one to go refer to the function declaration (or definition) to figure out what that value means.   We don't do a good job about this in general in codebase -- it'd be nice to start doing it right.

--
- Keith

From coleen.phillimore at oracle.com  Mon Oct 15 04:40:41 2012
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Mon, 15 Oct 2012 07:40:41 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507BB1EA.4040605@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com>
Message-ID: <507BF639.30807@oracle.com>


Nils,
I think you already know my opinion, which hasn't changed.
In webrev #3, if you revert one of the NMT changes, does it still 
compile?  Which "new" does it call?
If you add a new class and inherit from ResourceObj and like a good C++ 
programmer define a new with and without std::nothrow, which new does 
that call?   You might not like the name std::nothrow but it's what the 
C++ committee picked.
Scott Meyers "Effective C++" p27 Memory Management Item 9 "Avoid hiding 
the global new".  This was written before nothrow though and was a 
guideline for other reasons.  I haven't gotten to the modern version of 
this book but I assume the advice is the same.
I think the enum is great for documentation for the functions that are 
Hotspot specific.   For functions in the c++ standard that we overload, 
they should have the correct signature if the meaning is the same, ie 
std::nothrow.
Thanks,
Coleen

On 10/15/2012 2:49 AM, David Holmes wrote:
> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>
>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>
>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>> So in general we have two competing wishes here:
>>>>
>>>> 1. Use std::nothrow, in operator new() and enum in the allocation 
>>>> methods. (basically webrev 03)
>>>> Pros: more c++ standard-ish
>>>> cons: more boiler plate, not descriptive of what actually happens, 
>>>> two different mechanisms.
>>>>
>>>>
>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>> pros: more accurate description, cleaner implementation
>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're 
>>>> making up our own stuff.
>>>
>>> I'm less supportive of using an Enum over a boolean now. A 
>>> two-valued enum is a boolean. And we are treating it as a boolean 
>>> any time we use if-else rather than a switch-style selector - we 
>>> couldn't add a third option without revisiting every place it is 
>>> currently checked. And I just don't see there being any third option.
>>>
>> Remember that the point of not having a boolean wasn't to enable a 
>> potential third option, but to make callsites clearer.
>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>
> Okay, but a bool constant has the same properties (and is used 
> elsewhere in the VM).
>
> David
> ------
>
>>
>>
>>
>>> I never liked std::nothrow because we never threw in the first 
>>> place, but if it had instead been std::return_null I would have been 
>>> fine with it. But given we use custom multi-arg variants of operator 
>>> new I don't see that the "familiarity"/"standard" argument really 
>>> has that much weight. If anything using a standard feature in a 
>>> non-standard environment is likely to be more confusing to people 
>>> who might naturally expect that if they see a no_throw variant then 
>>> the other variant will in fact throw, not abort the VM!
>>>
>>> I have some specific comments on specific changes but there doesn't 
>>> seem much point going to that level of discussion yet. Except I will 
>>> mention that in thread.cpp the pre-existing throw_excpt argument to 
>>> allocate seems to really mean "exit_out_of_memory" and should be 
>>> renamed.
>>>
>>> David
>>> -----
>>>
>>>> So.. discuss! John, what do you think having seen the different 
>>>> implementations? It would be nice to be able to get in any version 
>>>> of it so I can develop the feature that will depend on it... :)
>>>>
>>>> Regards,
>>>> Nisse
>>>>
>>>> On Oct 12, 2012, at 17:03 , Coleen 
>>>> Phillimore<coleen.phillimore at oracle.com>   wrote:
>>>>
>>>>>
>>>>> I still prefer webrev 03 to webrev 04.   std::nothrow as a 
>>>>> parameter means something to any C++ developer and 
>>>>> AllocationStrategy::OOM only means something to a hotspot 
>>>>> developer.  I think we should use the standard C++ apis when 
>>>>> possible.  The duplication of operator new is not significant.   
>>>>> Plus if someone adds new (std::nothrow) call or you forgot to 
>>>>> clean up one, it think it will overload to the std::operator new() 
>>>>> which could lead to a subtle bug.
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 12 okt 2012 kl. 16:25 skrev Keith 
>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>
>>>>>>> May as well lift the allocation fail strategy up into 
>>>>>>> Thread::allocate() as well, replacing the boolean parameter there.
>>>>>>>
>>>>>> Ah, good idea.
>>>>>>
>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new 
>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to 
>>>>>>> replace it with RETURN_NULL.
>>>>>>>
>>>>>>> -
>>>>>> Argh, darn, you're right of course.
>>>>>>
>>>>>> Will fix.
>>>>>>
>>>>>>> - Keith
>>>>>>>
>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>
>>>>>>>> Hey guys!
>>>>>>>>
>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>> So I got rid of all the instances of std::nothrow throughout 
>>>>>>>> the code and replaced them with a new shiny and descriptive enum.
>>>>>>>>
>>>>>>>> Was able to fold together a few specialized operator new() 
>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>
>>>>>>>> What do you think now?
>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>
>>>>>>>> Have a nice weekend!
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nils Loodin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>> Hi Nils,
>>>>>>>>>>
>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not 
>>>>>>>>>> sure we
>>>>>>>>>> needed yet another.
>>>>>>>>>>
>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>> Hey guys.
>>>>>>>>>>>
>>>>>>>>>>> Your comments on this issue are great! So here's another 
>>>>>>>>>>> version that
>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there 
>>>>>>>>>> aren't even
>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit 
>>>>>>>>> older than
>>>>>>>>> that: April 2011. See
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>
>>>>>>>>> and some comments in
>>>>>>>>>
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>
>>>>>>>>> Till then we had avoided any use of C++ std:: stuff - 
>>>>>>>>> particularly
>>>>>>>>> anything related to the exception mechanism, which we don't 
>>>>>>>>> use at all.
>>>>>>>>>
>>>>>>>>>> any exceptions involved!) but introducing a completely different
>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail 
>>>>>>>>>> strategy"
>>>>>>>>>> approach but would like to see this solved holistically, 
>>>>>>>>>> replacing
>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM 
>>>>>>>>>> handle all
>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd 
>>>>>>>>>> rather not see
>>>>>>>>>> just another point-patch put in place.
>>>>>>>>> The bigger problem is probably still too big to really handle 
>>>>>>>>> - so
>>>>>>>>> either copy what we already introduced for CHeapObj to 
>>>>>>>>> ResourceObj for
>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> For the record I found the original proposal extremely 
>>>>>>>>>> confusing:
>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>
>>>>>>>>>> Sorry.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>> Keith,
>>>>>>>>>>>>
>>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...) 
>>>>>>>>>>>> function.
>>>>>>>>>>>>
>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is 
>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>> other than it should be done in a way that's maintainable 
>>>>>>>>>>>>> going
>>>>>>>>>>>>> forward
>>>>>>>>>>>>> and easily understandable by future generations of hotspot 
>>>>>>>>>>>>> developers.
>>>>>>>>>>>>> With this in mind, the only potential solution that I 
>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>> using a boolean with naked true/false values as 
>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural 
>>>>>>>>>>>>> way to do
>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is 
>>>>>>>>>>>>> already
>>>>>>>>>>>>> present
>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to 
>>>>>>>>>>>>> simple just
>>>>>>>>>>>>> add
>>>>>>>>>>>>> a new value to use. However if this ends up being 
>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we 
>>>>>>>>>>>>> can do
>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> - Keith
>>>>
>>

From david.holmes at oracle.com  Mon Oct 15 04:52:33 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 21:52:33 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <7BC852ED-5DF2-4641-BBD6-457806D44127@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
	<507B4658.5090401@oracle.com>
	<7BC852ED-5DF2-4641-BBD6-457806D44127@oracle.com>
Message-ID: <507BF901.9040506@oracle.com>

On 15/10/2012 9:31 PM, Keith McGuigan wrote:
>
> On Oct 14, 2012, at 7:10 PM, David Holmes wrote:
>
>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>> So in general we have two competing wishes here:
>>>
>>> 1. Use std::nothrow, in operator new() and enum in the allocation methods. (basically webrev 03)
>>> Pros: more c++ standard-ish
>>> cons: more boiler plate, not descriptive of what actually happens, two different mechanisms.
>>>
>>>
>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>> pros: more accurate description, cleaner implementation
>>> cons: it's an instance of "not invented here"-syndrom, ie, we're making up our own stuff.
>>
>> I'm less supportive of using an Enum over a boolean now. A two-valued enum is a boolean.
>
> I disagree.  A two-valued enum adds code readability to the code, though I'm sure the resulting machine code is the same.  I'd much rather see a self-describing name at the callsite than a naked 'true' or 'false which requires one to go refer to the function declaration (or definition) to figure out what that value means.   We don't do a good job about this in general in codebase -- it'd be nice to start doing it right.

A boolean constant can achieve the same call-site readability. If the 
parameter is "bool abort_on_oom" then you can have

const bool Alloc::ABORT_ON_OOM = true;
const bool Alloc::RETURN_NULL = false;

But this is a minor and mostly stylistic issue.

David

> --
> - Keith

From keith.mcguigan at oracle.com  Mon Oct 15 05:00:31 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Mon, 15 Oct 2012 08:00:31 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507BF901.9040506@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
	<507B4658.5090401@oracle.com>
	<7BC852ED-5DF2-4641-BBD6-457806D44127@oracle.com>
	<507BF901.9040506@oracle.com>
Message-ID: <507BFADF.5080001@oracle.com>



On 10/15/2012 7:52 AM, David Holmes wrote:
> A boolean constant can achieve the same call-site readability. If the
> parameter is "bool abort_on_oom" then you can have
>
> const bool Alloc::ABORT_ON_OOM = true;
> const bool Alloc::RETURN_NULL = false;
>
> But this is a minor and mostly stylistic issue.

Yeah, ok, I could get behind that too.  A typedef'd enum would be a 
little more forcing that the symbolic names were used, but this isn't 
bad either.

--
- Keith

From david.holmes at oracle.com  Mon Oct 15 05:01:22 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 22:01:22 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507BF639.30807@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
Message-ID: <507BFB12.2040401@oracle.com>

On 15/10/2012 9:40 PM, Coleen Phillmore wrote:
>
> Nils,
> I think you already know my opinion, which hasn't changed.
> In webrev #3, if you revert one of the NMT changes, does it still
> compile? Which "new" does it call?
> If you add a new class and inherit from ResourceObj and like a good C++
> programmer define a new with and without std::nothrow, which new does
> that call? You might not like the name std::nothrow but it's what the
> C++ committee picked.
> Scott Meyers "Effective C++" p27 Memory Management Item 9 "Avoid hiding
> the global new". This was written before nothrow though and was a
> guideline for other reasons. I haven't gotten to the modern version of
> this book but I assume the advice is the same.
> I think the enum is great for documentation for the functions that are
> Hotspot specific. For functions in the c++ standard that we overload,
> they should have the correct signature if the meaning is the same, ie
> std::nothrow.

That's a hard argument to make when the "standard" operator new is 
supposed to throw an exception and ours don't.

Plus you can't just add subclasses with their own operator new without 
fully understanding what the hotspot memory allocation strategy is - the 
whole thing is completely customized. So arguments for "standard" are 
somewhat tenuous in my opinion.

But, as I said in my PS email, if all this was rewritten we'd be passing 
null back for OOM, so adding all this additional policy selection seems 
to be a step in the wrong direction. A minimal change to ResourceObj 
along the lines of what exists (std::nothrow) for CHeapObj seems the 
path of least resistance to me.

David

> Thanks,
> Coleen
>
> On 10/15/2012 2:49 AM, David Holmes wrote:
>> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>>
>>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>>
>>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>>> So in general we have two competing wishes here:
>>>>>
>>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>>> methods. (basically webrev 03)
>>>>> Pros: more c++ standard-ish
>>>>> cons: more boiler plate, not descriptive of what actually happens,
>>>>> two different mechanisms.
>>>>>
>>>>>
>>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>>> pros: more accurate description, cleaner implementation
>>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>>>>> making up our own stuff.
>>>>
>>>> I'm less supportive of using an Enum over a boolean now. A
>>>> two-valued enum is a boolean. And we are treating it as a boolean
>>>> any time we use if-else rather than a switch-style selector - we
>>>> couldn't add a third option without revisiting every place it is
>>>> currently checked. And I just don't see there being any third option.
>>>>
>>> Remember that the point of not having a boolean wasn't to enable a
>>> potential third option, but to make callsites clearer.
>>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>>
>> Okay, but a bool constant has the same properties (and is used
>> elsewhere in the VM).
>>
>> David
>> ------
>>
>>>
>>>
>>>
>>>> I never liked std::nothrow because we never threw in the first
>>>> place, but if it had instead been std::return_null I would have been
>>>> fine with it. But given we use custom multi-arg variants of operator
>>>> new I don't see that the "familiarity"/"standard" argument really
>>>> has that much weight. If anything using a standard feature in a
>>>> non-standard environment is likely to be more confusing to people
>>>> who might naturally expect that if they see a no_throw variant then
>>>> the other variant will in fact throw, not abort the VM!
>>>>
>>>> I have some specific comments on specific changes but there doesn't
>>>> seem much point going to that level of discussion yet. Except I will
>>>> mention that in thread.cpp the pre-existing throw_excpt argument to
>>>> allocate seems to really mean "exit_out_of_memory" and should be
>>>> renamed.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> So.. discuss! John, what do you think having seen the different
>>>>> implementations? It would be nice to be able to get in any version
>>>>> of it so I can develop the feature that will depend on it... :)
>>>>>
>>>>> Regards,
>>>>> Nisse
>>>>>
>>>>> On Oct 12, 2012, at 17:03 , Coleen
>>>>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>>>>
>>>>>>
>>>>>> I still prefer webrev 03 to webrev 04. std::nothrow as a parameter
>>>>>> means something to any C++ developer and AllocationStrategy::OOM
>>>>>> only means something to a hotspot developer. I think we should use
>>>>>> the standard C++ apis when possible. The duplication of operator
>>>>>> new is not significant. Plus if someone adds new (std::nothrow)
>>>>>> call or you forgot to clean up one, it think it will overload to
>>>>>> the std::operator new() which could lead to a subtle bug.
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 12 okt 2012 kl. 16:25 skrev Keith
>>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>>
>>>>>>>> May as well lift the allocation fail strategy up into
>>>>>>>> Thread::allocate() as well, replacing the boolean parameter there.
>>>>>>>>
>>>>>>> Ah, good idea.
>>>>>>>
>>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to
>>>>>>>> replace it with RETURN_NULL.
>>>>>>>>
>>>>>>>> -
>>>>>>> Argh, darn, you're right of course.
>>>>>>>
>>>>>>> Will fix.
>>>>>>>
>>>>>>>> - Keith
>>>>>>>>
>>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>>
>>>>>>>>> Hey guys!
>>>>>>>>>
>>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>>> So I got rid of all the instances of std::nothrow throughout
>>>>>>>>> the code and replaced them with a new shiny and descriptive enum.
>>>>>>>>>
>>>>>>>>> Was able to fold together a few specialized operator new()
>>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>>
>>>>>>>>> What do you think now?
>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>>
>>>>>>>>> Have a nice weekend!
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Nils Loodin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>
>>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not
>>>>>>>>>>> sure we
>>>>>>>>>>> needed yet another.
>>>>>>>>>>>
>>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>
>>>>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>>>>> version that
>>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>>>>> aren't even
>>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit
>>>>>>>>>> older than
>>>>>>>>>> that: April 2011. See
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>>
>>>>>>>>>> and some comments in
>>>>>>>>>>
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>>
>>>>>>>>>> Till then we had avoided any use of C++ std:: stuff -
>>>>>>>>>> particularly
>>>>>>>>>> anything related to the exception mechanism, which we don't
>>>>>>>>>> use at all.
>>>>>>>>>>
>>>>>>>>>>> any exceptions involved!) but introducing a completely different
>>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail
>>>>>>>>>>> strategy"
>>>>>>>>>>> approach but would like to see this solved holistically,
>>>>>>>>>>> replacing
>>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>>>>> handle all
>>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd
>>>>>>>>>>> rather not see
>>>>>>>>>>> just another point-patch put in place.
>>>>>>>>>> The bigger problem is probably still too big to really handle
>>>>>>>>>> - so
>>>>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>>>>> ResourceObj for
>>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> For the record I found the original proposal extremely
>>>>>>>>>>> confusing:
>>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>>
>>>>>>>>>>> Sorry.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>>> Keith,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...)
>>>>>>>>>>>>> function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>>> other than it should be done in a way that's maintainable
>>>>>>>>>>>>>> going
>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>> and easily understandable by future generations of hotspot
>>>>>>>>>>>>>> developers.
>>>>>>>>>>>>>> With this in mind, the only potential solution that I
>>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>>> using a boolean with naked true/false values as
>>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural
>>>>>>>>>>>>>> way to do
>>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is
>>>>>>>>>>>>>> already
>>>>>>>>>>>>>> present
>>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>>>>> simple just
>>>>>>>>>>>>>> add
>>>>>>>>>>>>>> a new value to use. However if this ends up being
>>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we
>>>>>>>>>>>>>> can do
>>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> - Keith
>>>>>
>>>

From vitalyd at gmail.com  Mon Oct 15 05:03:05 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 15 Oct 2012 08:03:05 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507BF901.9040506@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>
	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>
	<5075DD16.8070602@oracle.com>
	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>
	<5075E05C.90608@oracle.com>
	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>
	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>
	<50760770.4030403@oracle.com> <5076ABCF.5020005@oracle.com>
	<5076C1C2.30408@oracle.com> <50779AAD.30108@oracle.com>
	<5077A0CD.2030503@oracle.com> <507817AF.1040900@oracle.com>
	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>
	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>
	<5078313B.60404@oracle.com>
	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>
	<507B4658.5090401@oracle.com>
	<7BC852ED-5DF2-4641-BBD6-457806D44127@oracle.com>
	<507BF901.9040506@oracle.com>
Message-ID: <CAHjP37HbvQeB3HqQbZvVWJb7O85jRuV_4WfR9AZ5xxM2j2VofA@mail.gmail.com>

An enum also provides more type safety than a bool.  If you're only ever
explicitly calling these functions with the constants, it doesn't matter;
but if you're passing the result of another function call, then it could
matter.

Sent from my phone
On Oct 15, 2012 7:54 AM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 15/10/2012 9:31 PM, Keith McGuigan wrote:
>
>>
>> On Oct 14, 2012, at 7:10 PM, David Holmes wrote:
>>
>>  On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>
>>>> So in general we have two competing wishes here:
>>>>
>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>> methods. (basically webrev 03)
>>>> Pros: more c++ standard-ish
>>>> cons: more boiler plate, not descriptive of what actually happens, two
>>>> different mechanisms.
>>>>
>>>>
>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>> pros: more accurate description, cleaner implementation
>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're making
>>>> up our own stuff.
>>>>
>>>
>>> I'm less supportive of using an Enum over a boolean now. A two-valued
>>> enum is a boolean.
>>>
>>
>> I disagree.  A two-valued enum adds code readability to the code, though
>> I'm sure the resulting machine code is the same.  I'd much rather see a
>> self-describing name at the callsite than a naked 'true' or 'false which
>> requires one to go refer to the function declaration (or definition) to
>> figure out what that value means.   We don't do a good job about this in
>> general in codebase -- it'd be nice to start doing it right.
>>
>
> A boolean constant can achieve the same call-site readability. If the
> parameter is "bool abort_on_oom" then you can have
>
> const bool Alloc::ABORT_ON_OOM = true;
> const bool Alloc::RETURN_NULL = false;
>
> But this is a minor and mostly stylistic issue.
>
> David
>
>  --
>> - Keith
>>
>

From vladimir.x.ivanov at oracle.com  Mon Oct 15 08:50:56 2012
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 15 Oct 2012 19:50:56 +0400
Subject: Why MACOSX_UNIVERSAL == true by default?
In-Reply-To: <507889E1.1090707@oracle.com>
References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com>
Message-ID: <507C30E0.4070205@oracle.com>

Thanks everybody for the background information!

Are there any objections to set MACOSX_UNIVERSAL=false by default during
Hotspot build then?

Best regards,
Vladimir Ivanov

On 10/13/12 01:21, Daniel D. Daugherty wrote:
> Adding macosx-port-dev at ... to the thread...
> 
> 
> On 10/12/12 2:56 PM, Vladimir Ivanov wrote:
>> Hi,
>>
>> Does anybody know/remember why MACOSX_UNIVERSAL=true by default?
> 
> Yes. :-)
> 
> 
>> I'm asking, because JDK layout on MacOS X differs from other platforms
>> and to make export_*_jdk build targets work correctly, you need to
>> specify ALT_MACOSX_UNIVERSAL=false.
>>
>> I'd like to fix that (change default value to false), but I have no
>> idea why it was set to true in the first place.
> 
> Jim Melvin restored Universal build support into HotSpot. However,
> the rest of the JDK did not follow suit. As far as I know/remember,
> only the hotspot repo supports Universal build at the moment.
> 
> Dan
> 
>>
>> Best regards,
>> Vladimir Ivanov

From john.cuthbertson at oracle.com  Mon Oct 15 09:13:10 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 15 Oct 2012 09:13:10 -0700
Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete
In-Reply-To: <CABzyjynSfKuPmtuhYmnARZY_eSYt1p=An_YE-2AC_B-4ofOvHw@mail.gmail.com>
References: <5078A50C.6050508@oracle.com>
	<CABzyjynSfKuPmtuhYmnARZY_eSYt1p=An_YE-2AC_B-4ofOvHw@mail.gmail.com>
Message-ID: <507C3616.1080501@oracle.com>

Hi Ramki,

Thanks for the review. I couldn't find any callers where silent was 
being passed true. The ones that surprised me were the calls at JVM 
start and end, and the one in jvmtiTagMap.cpp. I was expecting these to 
be silent.

Regards,

JohnC


On 10/14/12 23:06, Srinivas Ramakrishna wrote:
> Changes look fine. (I wonder though if there are any callers of the 
> "silent" verification option at all now.... Can't recall if the slinet 
> mode was ever used and if so when; and don't have the source code 
> handy to check right now.)
>
> -- ramki
>
> On Fri, Oct 12, 2012 at 4:17 PM, John Cuthbertson 
> <john.cuthbertson at oracle.com <mailto:john.cuthbertson at oracle.com>> wrote:
>
>     Hi Everyone,
>
>     Can I have a couple of volunteers review the fix for this CR - the
>     webrev can be found at:
>     http://cr.openjdk.java.net/~johnc/8000831/webrev.0/
>     <http://cr.openjdk.java.net/%7Ejohnc/8000831/webrev.0/>
>
>     Summary:
>     An earlier change inadvertently turned off part of the output of
>     heap verification:
>
>     [Verifying threads syms strs zone dict hand C-heap code cache ]
>     VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)]
>     16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00,
>     real=0.02 secs]
>     VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)]
>     17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00,
>     real=0.01 secs]
>     VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)]
>     17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03,
>     real=0.06 secs]
>     VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)]
>     17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00,
>     real=0.02 secs]
>     VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)]
>     34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04,
>     real=0.09 secs]
>     VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)]
>     35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00,
>     real=0.03 secs]
>     VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)]
>     69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11,
>     real=0.20 secs]
>
>     Previously it was:
>
>     [Verifying threads syms strs zone dict hand C-heap code cache ]
>     VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs
>     zone dict hand C-heap code cache ]
>     4.818: [GC [PSYoungGen: 16896K->392K(19712K)]
>     16896K->396K(62720K), 0.0244147 secs] [Times: user=0.02 sys=0.00,
>     real=0.02 secs]
>     VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs
>     zone dict hand C-heap code cache ]
>     5.087: [GC [PSYoungGen: 17288K->392K(19712K)]
>     17292K->400K(62720K), 0.0597174 secs] [Times: user=0.04 sys=0.03,
>     real=0.06 secs]
>     VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs
>     zone dict hand C-heap code cache ]
>     5.410: [GC [PSYoungGen: 17288K->400K(19712K)]
>     17296K->412K(62720K), 0.0173056 secs] [Times: user=0.02 sys=0.00,
>     real=0.02 secs]
>     VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs
>     zone dict hand C-heap code cache ]
>     5.595: [GC [PSYoungGen: 17296K->400K(36608K)]
>     17308K->416K(79616K), 0.0134239 secs] [Times: user=0.02 sys=0.00,
>     real=0.01 secs]
>
>     The changes restore the previous output for the affected collectors.
>
>     Testing:
>     GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with
>     serial, parallel, concurrent, and G1 collectors.
>
>     Thanks,
>
>     JohnC
>
>


From christian.thalinger at oracle.com  Mon Oct 15 16:38:55 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 15 Oct 2012 16:38:55 -0700
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1350044523.1682.33.camel@moonlight>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<1349989134.1682.18.camel@moonlight> <5077FDBB.6060609@oracle.com>
	<1350044523.1682.33.camel@moonlight>
Message-ID: <3A1AAED5-060B-4293-A91E-8EDAD79F27B0@oracle.com>


On Oct 12, 2012, at 5:22 AM, Roman Kennke <rkennke at redhat.com> wrote:

> Am Freitag, den 12.10.2012, 07:23 -0400 schrieb Coleen Phillmore:
>> Hi,
>> I looked at this briefly and it looks okay from the cpp interpreter 
>> part.  Thank you for getting zero working again.   We tried to keep it 
>> in sync with the permgen removal changes but didn't regularly test 
>> this.   Hello world as a test for this is probably enough to verify your 
>> changes to the non-JSR292 part.
>> For JSR292 testing, you need to get a full jdk repository and go to the 
>> jdk/test/java/lang/invoke and run the tests with jtreg.   How to run and 
>> install jtreg is on the openjdk pages, and it's happily easy to do.
> 
> Ah, and before you mention it as well, I downloaded and run JRuby, the
> examples that ship with JRuby run just as well with Zero as they do with
> x86 hotspot. However, I am not sure if this exercises JSR292 or not, or
> what would be necessary to do so, etc.

If you're running on 8 it uses invokedynamic (JRuby disabled invokedynamic for 7).  For 7 you can turn it on with -Xcompile.invokedynamic=true (note the +indy in the version string):

$ jruby -v -e ""
jruby 1.7.0.RC2 (1.9.3p203) 2012-10-12 3b90805 on Java HotSpot(TM) Server VM 1.8.0-ea-b60 +indy [SunOS-x86]
$ jruby -v 
jruby 1.7.0.RC2 (1.9.3p203) 2012-10-12 3b90805 on Java HotSpot(TM) Server VM 1.7.0_10-ea-b11 [SunOS-x86]
$ jruby -v -Xcompile.invokedynamic=true
jruby 1.7.0.RC2 (1.9.3p203) 2012-10-12 3b90805 on Java HotSpot(TM) Server VM 1.7.0_10-ea-b11 +indy [SunOS-x86]

-- Chris

> 
> Roman
> 
> 


From christian.thalinger at oracle.com  Mon Oct 15 16:47:13 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 15 Oct 2012 16:47:13 -0700
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1349988670.1682.16.camel@moonlight>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
	<1349988670.1682.16.camel@moonlight>
Message-ID: <F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>


On Oct 11, 2012, at 1:51 PM, Roman Kennke <rkennke at redhat.com> wrote:

> Hi Christian,
> 
> Thanks for the fast reply!
> 
>>>> In the recent weeks I worked on the Zero interpreter, to get it to build
>>>> and run with JDK8, and in particular with the latest changes that came
>>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>>>> 
>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>> 
>> src/share/vm/asm/codeBuffer.cpp:
>> 
>> -  if (dest->blob() == NULL) {
>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>> 
>> Do we really need this when you have this:
> 
> The above is needed, because the loop above it that initializes
> dest_filled is never executed. However, I will change the test to
> dest_filled != NULL :-)
> 
>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>> 
>> -  memset(to, value, count);
>> +  if ( count > 0 ) memset(to, value, count);
>> 
>> }
> 
> Turns out that this is 1. not related to the other change above and 2.
> not needed. I'll remove it.
> 
>> src/share/vm/interpreter/interpreter.cpp:
>> 
>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
>> 
>> Why did you need that change?
> 
> Apparently, before the whole table was initialized, and the methodhandle
> related entries left as abstract. Now the methodhandle entries are
> simply left to NULL. I suppose we could change the assert to 
> 
> assert(_entry_table[kind] == NULL, "previous value must be NULL");
> 
> Alternatively, we could fix the code that puts the other entries to also
> set the methodhandle entries to AME and go back to the original assert.
> What do you think?

TemplateInterpreterGenerator::generate_all sets all MH entries to AME:

  // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
  for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
    Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
    Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
  }                                                                                                                                                              

You need similar code in Zero.

-- Chris

> 
> Roman
> 
>> -- Chris
>> 
>>>> 
>>>> A few notes on the patch:
>>>> - Some makefile changes have been necessary to get it to build at all.
>>>> - A bunch of stub functions needed to be added to make the compiler
>>>> happy, they should not be called though.
>>>> - Most of the changes are related to JSR292 stuff, in particular the
>>>> added invokehandle handler, and the changes to invokedynamic resulting
>>>> from how the constant pool entry has changed (e.g. method is now in f1).
>>>> - A lot of code relating to JSR292 could be removed because most of the
>>>> logic has been moved to the (Java) lambda forms.
>>>> - A few native methods have been added (MH.invokeBasic(),
>>>> MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
>>>> 
>>>> With those changes it's possible to build the Zero-JDK with itself, and
>>>> run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
>>>> TCK or such, this would have to wait until all this gets backported to
>>>> JDK7 anyway, and I wanted to get some feedback on the changes first.
>>> 
>>> You may want to run something like JRuby as well.
>>> 
>>>> 
>>>> So what do you think?
>>>> 
>>>> And what are the next steps to (hopefully) get those changes committed?
>>>> I guess I need a bug-ID and formal review ?
>>> 
>>> Yes, you do.  Here is the bug:
>>> 
>>> 8000780: make Zero build and run with JDK8
>>> 
>>> I'm reviewing the changes right now...
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> And in case this is not the correct mailing list, please fwd to and/or
>>>> CC the correct list.
>>>> 
>>>> Thanks and kind regards,
>>>> Roman
>>>> 
>>>> 
>>> 
>> 
> 
> 


From darryl-mailinglists at netbauds.net  Tue Oct 16 05:57:47 2012
From: darryl-mailinglists at netbauds.net (Darryl L. Miles)
Date: Tue, 16 Oct 2012 13:57:47 +0100
Subject: JNI DetachCurrentThread() usage during JVM process exit
Message-ID: <507D59CB.4020602@netbauds.net>


I am trying to understand the reasons why the JNI method 
DetachCurrentThread()  blocks the thread in VM_Exit::wait_if_vm_exited() 
instead of returning control back to JNI during process exit proceedings.

This is particular problematic when the thread in question is actually 
owned by JNI (because it started out life with JNI using 
pthread_create() directly).



Sequence of events:

* java.exe starts up
* JAR loaded and JNI *.so loaded
* addShutdownHook() thread added
* application uses/implements JNI based thread pool, this creates a 
thread, that does work, completes and stays idle in pool.  During the 
time of doing work it performs a JNI AttachCurrentThreadAsDaemon() so it 
can call into Java.  Not all JNI threads created call into Java, they 
are attached to VM on their first invocation into Java and remain 
attached.  If the thread pool prunes (terminates) idle workers, those 
threads will call DetachCurrentThread() if they had been attached before 
the worker thread exits.
* The Application decides to exit, the JNI based thread pool has no 
active threads but may have management thread and one or more workers 
that are idle in the pool.
* System.exit() is called.
* addShutdownHook() thread started and run
* From the shutdownHook thread this instructs the JNI based thread pool 
to close, during this close each worker thread that did an 
'AttachCurrentThreadAsDaemon()' will perform a 'DetachCurrentThread()'.  
These threads hang because the JVM never returns control back to JNI.  
These threads are owned by JNI (not by Java) so they may have further 
clean up to do and will then exit if the DetachCurrentThread() were to 
return control.
* The addShutdownHook() thread deadlocks waiting for the JNI thread pool 
to close.



I can understand if the thread started out life as Java Thread object or 
as an internal house keeping thread (that scenario is unlikely to call 
any of my JNI).

But when the thread started out life from JNI using pthread_create() and 
then was introduced to the JVM, I think that JNI DetachCurrentThread() 
should not block even on exit under these circumstances.  If anything 
the DetachCurrentThread() is signalling that Java has no further need to 
worry about this thread anymore, i.e. it can not invoke any Java.  
Obviously I would expect the JVM to refuse any further Attach requests 
under a VM_Exit scenario.

I think JVM thread accounting should handle this case, maybe defer TLS 
cleanup if it is not possible to touch some data due to locking, or just 
never cleanup if the process is going to terminate anyway.


TIA,

Darryl


From coleen.phillimore at oracle.com  Tue Oct 16 06:08:08 2012
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Tue, 16 Oct 2012 09:08:08 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507BFB12.2040401@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com>
Message-ID: <507D5C38.8050409@oracle.com>


Hi, I still disagree.

On 10/15/2012 8:01 AM, David Holmes wrote:
> On 15/10/2012 9:40 PM, Coleen Phillmore wrote:
>>
>> Nils,
>> I think you already know my opinion, which hasn't changed.
>> In webrev #3, if you revert one of the NMT changes, does it still
>> compile? Which "new" does it call?
>> If you add a new class and inherit from ResourceObj and like a good C++
>> programmer define a new with and without std::nothrow, which new does
>> that call? You might not like the name std::nothrow but it's what the
>> C++ committee picked.
>> Scott Meyers "Effective C++" p27 Memory Management Item 9 "Avoid hiding
>> the global new". This was written before nothrow though and was a
>> guideline for other reasons. I haven't gotten to the modern version of
>> this book but I assume the advice is the same.
>> I think the enum is great for documentation for the functions that are
>> Hotspot specific. For functions in the c++ standard that we overload,
>> they should have the correct signature if the meaning is the same, ie
>> std::nothrow.
>
> That's a hard argument to make when the "standard" operator new is 
> supposed to throw an exception and ours don't.

That's why it's overloaded.   The std::nothrow variant does exactly what 
the one would expect from that variation, on the other hand.
>
> Plus you can't just add subclasses with their own operator new without 
> fully understanding what the hotspot memory allocation strategy is - 
> the whole thing is completely customized. So arguments for "standard" 
> are somewhat tenuous in my opinion.

Enforcing this with the proper overloading and in the code beats having 
attentive human code reviewers!   If we follow the standard, then new 
developers or openjdk developers already understand at least this part 
of the code because they know C++.

>
> But, as I said in my PS email, if all this was rewritten we'd be 
> passing null back for OOM, so adding all this additional policy 
> selection seems to be a step in the wrong direction. A minimal change 
> to ResourceObj along the lines of what exists (std::nothrow) for 
> CHeapObj seems the path of least resistance to me.
>

Actually to throw OOM, you'd change the throw version of the operator 
new, not the nothrow version.   The nothrow version should be just that.

My main concern is unintended consequences of hiding or overloading to 
the wrong operator new.  There's some code in allocation.cpp that tries 
to catch code that unintentionally uses the global operator new, which 
is disabled.    Part of adding the nonstandard overloading operator new 
should be enabling this code with the nothrow version.   I think this is 
more additional work.

I think Nils version _03 of this change is really good and they need it 
for JFR now.   I don't think we should hold it hostage to this 
disagreement on this issue.  I also don't have time to read the rest of 
Scott Meyer's books right now to use his arguments why this is dangerous.

Thanks,
Coleen
> David
>
>> Thanks,
>> Coleen
>>
>> On 10/15/2012 2:49 AM, David Holmes wrote:
>>> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>>>
>>>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>>>
>>>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>>>> So in general we have two competing wishes here:
>>>>>>
>>>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>>>> methods. (basically webrev 03)
>>>>>> Pros: more c++ standard-ish
>>>>>> cons: more boiler plate, not descriptive of what actually happens,
>>>>>> two different mechanisms.
>>>>>>
>>>>>>
>>>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>>>> pros: more accurate description, cleaner implementation
>>>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>>>>>> making up our own stuff.
>>>>>
>>>>> I'm less supportive of using an Enum over a boolean now. A
>>>>> two-valued enum is a boolean. And we are treating it as a boolean
>>>>> any time we use if-else rather than a switch-style selector - we
>>>>> couldn't add a third option without revisiting every place it is
>>>>> currently checked. And I just don't see there being any third option.
>>>>>
>>>> Remember that the point of not having a boolean wasn't to enable a
>>>> potential third option, but to make callsites clearer.
>>>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>>>
>>> Okay, but a bool constant has the same properties (and is used
>>> elsewhere in the VM).
>>>
>>> David
>>> ------
>>>
>>>>
>>>>
>>>>
>>>>> I never liked std::nothrow because we never threw in the first
>>>>> place, but if it had instead been std::return_null I would have been
>>>>> fine with it. But given we use custom multi-arg variants of operator
>>>>> new I don't see that the "familiarity"/"standard" argument really
>>>>> has that much weight. If anything using a standard feature in a
>>>>> non-standard environment is likely to be more confusing to people
>>>>> who might naturally expect that if they see a no_throw variant then
>>>>> the other variant will in fact throw, not abort the VM!
>>>>>
>>>>> I have some specific comments on specific changes but there doesn't
>>>>> seem much point going to that level of discussion yet. Except I will
>>>>> mention that in thread.cpp the pre-existing throw_excpt argument to
>>>>> allocate seems to really mean "exit_out_of_memory" and should be
>>>>> renamed.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> So.. discuss! John, what do you think having seen the different
>>>>>> implementations? It would be nice to be able to get in any version
>>>>>> of it so I can develop the feature that will depend on it... :)
>>>>>>
>>>>>> Regards,
>>>>>> Nisse
>>>>>>
>>>>>> On Oct 12, 2012, at 17:03 , Coleen
>>>>>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> I still prefer webrev 03 to webrev 04. std::nothrow as a parameter
>>>>>>> means something to any C++ developer and AllocationStrategy::OOM
>>>>>>> only means something to a hotspot developer. I think we should use
>>>>>>> the standard C++ apis when possible. The duplication of operator
>>>>>>> new is not significant. Plus if someone adds new (std::nothrow)
>>>>>>> call or you forgot to clean up one, it think it will overload to
>>>>>>> the std::operator new() which could lead to a subtle bug.
>>>>>>>
>>>>>>> Coleen
>>>>>>>
>>>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 12 okt 2012 kl. 16:25 skrev Keith
>>>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>>>
>>>>>>>>> May as well lift the allocation fail strategy up into
>>>>>>>>> Thread::allocate() as well, replacing the boolean parameter 
>>>>>>>>> there.
>>>>>>>>>
>>>>>>>> Ah, good idea.
>>>>>>>>
>>>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to
>>>>>>>>> replace it with RETURN_NULL.
>>>>>>>>>
>>>>>>>>> -
>>>>>>>> Argh, darn, you're right of course.
>>>>>>>>
>>>>>>>> Will fix.
>>>>>>>>
>>>>>>>>> - Keith
>>>>>>>>>
>>>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>>>
>>>>>>>>>> Hey guys!
>>>>>>>>>>
>>>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>>>> So I got rid of all the instances of std::nothrow throughout
>>>>>>>>>> the code and replaced them with a new shiny and descriptive 
>>>>>>>>>> enum.
>>>>>>>>>>
>>>>>>>>>> Was able to fold together a few specialized operator new()
>>>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>>>
>>>>>>>>>> What do you think now?
>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>>>
>>>>>>>>>> Have a nice weekend!
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Nils Loodin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>>
>>>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not
>>>>>>>>>>>> sure we
>>>>>>>>>>>> needed yet another.
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>>>>>> version that
>>>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>>>>>> aren't even
>>>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit
>>>>>>>>>>> older than
>>>>>>>>>>> that: April 2011. See
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>>>
>>>>>>>>>>> and some comments in
>>>>>>>>>>>
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>>>
>>>>>>>>>>> Till then we had avoided any use of C++ std:: stuff -
>>>>>>>>>>> particularly
>>>>>>>>>>> anything related to the exception mechanism, which we don't
>>>>>>>>>>> use at all.
>>>>>>>>>>>
>>>>>>>>>>>> any exceptions involved!) but introducing a completely 
>>>>>>>>>>>> different
>>>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail
>>>>>>>>>>>> strategy"
>>>>>>>>>>>> approach but would like to see this solved holistically,
>>>>>>>>>>>> replacing
>>>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>>>>>> handle all
>>>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd
>>>>>>>>>>>> rather not see
>>>>>>>>>>>> just another point-patch put in place.
>>>>>>>>>>> The bigger problem is probably still too big to really handle
>>>>>>>>>>> - so
>>>>>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>>>>>> ResourceObj for
>>>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> For the record I found the original proposal extremely
>>>>>>>>>>>> confusing:
>>>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>> Keith,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...)
>>>>>>>>>>>>>> function.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>>>> other than it should be done in a way that's maintainable
>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>> and easily understandable by future generations of hotspot
>>>>>>>>>>>>>>> developers.
>>>>>>>>>>>>>>> With this in mind, the only potential solution that I
>>>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>>>> using a boolean with naked true/false values as
>>>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural
>>>>>>>>>>>>>>> way to do
>>>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. 
>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is
>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>>>>>> simple just
>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>> a new value to use. However if this ends up being
>>>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we
>>>>>>>>>>>>>>> can do
>>>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> - Keith
>>>>>>
>>>>

From coleen.phillimore at oracle.com  Tue Oct 16 06:22:54 2012
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Tue, 16 Oct 2012 09:22:54 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507D5C38.8050409@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>	<507BB1EA.4040605@oracle.com>
	<507BF639.30807@oracle.com>	<507BFB12.2040401@oracle.com>
	<507D5C38.8050409@oracle.com>
Message-ID: <507D5FAE.3090207@oracle.com>


For the record, here is webrev.03 dug out from the thread.

http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/

thanks,
Coleen

On 10/16/2012 9:08 AM, Coleen Phillmore wrote:
>
> Hi, I still disagree.
>
> On 10/15/2012 8:01 AM, David Holmes wrote:
>> On 15/10/2012 9:40 PM, Coleen Phillmore wrote:
>>>
>>> Nils,
>>> I think you already know my opinion, which hasn't changed.
>>> In webrev #3, if you revert one of the NMT changes, does it still
>>> compile? Which "new" does it call?
>>> If you add a new class and inherit from ResourceObj and like a good C++
>>> programmer define a new with and without std::nothrow, which new does
>>> that call? You might not like the name std::nothrow but it's what the
>>> C++ committee picked.
>>> Scott Meyers "Effective C++" p27 Memory Management Item 9 "Avoid hiding
>>> the global new". This was written before nothrow though and was a
>>> guideline for other reasons. I haven't gotten to the modern version of
>>> this book but I assume the advice is the same.
>>> I think the enum is great for documentation for the functions that are
>>> Hotspot specific. For functions in the c++ standard that we overload,
>>> they should have the correct signature if the meaning is the same, ie
>>> std::nothrow.
>>
>> That's a hard argument to make when the "standard" operator new is 
>> supposed to throw an exception and ours don't.
>
> That's why it's overloaded.   The std::nothrow variant does exactly 
> what the one would expect from that variation, on the other hand.
>>
>> Plus you can't just add subclasses with their own operator new 
>> without fully understanding what the hotspot memory allocation 
>> strategy is - the whole thing is completely customized. So arguments 
>> for "standard" are somewhat tenuous in my opinion.
>
> Enforcing this with the proper overloading and in the code beats 
> having attentive human code reviewers!   If we follow the standard, 
> then new developers or openjdk developers already understand at least 
> this part of the code because they know C++.
>
>>
>> But, as I said in my PS email, if all this was rewritten we'd be 
>> passing null back for OOM, so adding all this additional policy 
>> selection seems to be a step in the wrong direction. A minimal change 
>> to ResourceObj along the lines of what exists (std::nothrow) for 
>> CHeapObj seems the path of least resistance to me.
>>
>
> Actually to throw OOM, you'd change the throw version of the operator 
> new, not the nothrow version.   The nothrow version should be just that.
>
> My main concern is unintended consequences of hiding or overloading to 
> the wrong operator new.  There's some code in allocation.cpp that 
> tries to catch code that unintentionally uses the global operator new, 
> which is disabled.    Part of adding the nonstandard overloading 
> operator new should be enabling this code with the nothrow version.   
> I think this is more additional work.
>
> I think Nils version _03 of this change is really good and they need 
> it for JFR now.   I don't think we should hold it hostage to this 
> disagreement on this issue.  I also don't have time to read the rest 
> of Scott Meyer's books right now to use his arguments why this is 
> dangerous.
>
> Thanks,
> Coleen
>> David
>>
>>> Thanks,
>>> Coleen
>>>
>>> On 10/15/2012 2:49 AM, David Holmes wrote:
>>>> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>>>>
>>>>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>>>>
>>>>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>>>>> So in general we have two competing wishes here:
>>>>>>>
>>>>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>>>>> methods. (basically webrev 03)
>>>>>>> Pros: more c++ standard-ish
>>>>>>> cons: more boiler plate, not descriptive of what actually happens,
>>>>>>> two different mechanisms.
>>>>>>>
>>>>>>>
>>>>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>>>>> pros: more accurate description, cleaner implementation
>>>>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>>>>>>> making up our own stuff.
>>>>>>
>>>>>> I'm less supportive of using an Enum over a boolean now. A
>>>>>> two-valued enum is a boolean. And we are treating it as a boolean
>>>>>> any time we use if-else rather than a switch-style selector - we
>>>>>> couldn't add a third option without revisiting every place it is
>>>>>> currently checked. And I just don't see there being any third 
>>>>>> option.
>>>>>>
>>>>> Remember that the point of not having a boolean wasn't to enable a
>>>>> potential third option, but to make callsites clearer.
>>>>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>>>>
>>>> Okay, but a bool constant has the same properties (and is used
>>>> elsewhere in the VM).
>>>>
>>>> David
>>>> ------
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I never liked std::nothrow because we never threw in the first
>>>>>> place, but if it had instead been std::return_null I would have been
>>>>>> fine with it. But given we use custom multi-arg variants of operator
>>>>>> new I don't see that the "familiarity"/"standard" argument really
>>>>>> has that much weight. If anything using a standard feature in a
>>>>>> non-standard environment is likely to be more confusing to people
>>>>>> who might naturally expect that if they see a no_throw variant then
>>>>>> the other variant will in fact throw, not abort the VM!
>>>>>>
>>>>>> I have some specific comments on specific changes but there doesn't
>>>>>> seem much point going to that level of discussion yet. Except I will
>>>>>> mention that in thread.cpp the pre-existing throw_excpt argument to
>>>>>> allocate seems to really mean "exit_out_of_memory" and should be
>>>>>> renamed.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> So.. discuss! John, what do you think having seen the different
>>>>>>> implementations? It would be nice to be able to get in any version
>>>>>>> of it so I can develop the feature that will depend on it... :)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nisse
>>>>>>>
>>>>>>> On Oct 12, 2012, at 17:03 , Coleen
>>>>>>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I still prefer webrev 03 to webrev 04. std::nothrow as a parameter
>>>>>>>> means something to any C++ developer and AllocationStrategy::OOM
>>>>>>>> only means something to a hotspot developer. I think we should use
>>>>>>>> the standard C++ apis when possible. The duplication of operator
>>>>>>>> new is not significant. Plus if someone adds new (std::nothrow)
>>>>>>>> call or you forgot to clean up one, it think it will overload to
>>>>>>>> the std::operator new() which could lead to a subtle bug.
>>>>>>>>
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 12 okt 2012 kl. 16:25 skrev Keith
>>>>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>>>>
>>>>>>>>>> May as well lift the allocation fail strategy up into
>>>>>>>>>> Thread::allocate() as well, replacing the boolean parameter 
>>>>>>>>>> there.
>>>>>>>>>>
>>>>>>>>> Ah, good idea.
>>>>>>>>>
>>>>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to
>>>>>>>>>> replace it with RETURN_NULL.
>>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>> Argh, darn, you're right of course.
>>>>>>>>>
>>>>>>>>> Will fix.
>>>>>>>>>
>>>>>>>>>> - Keith
>>>>>>>>>>
>>>>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey guys!
>>>>>>>>>>>
>>>>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>>>>> So I got rid of all the instances of std::nothrow throughout
>>>>>>>>>>> the code and replaced them with a new shiny and descriptive 
>>>>>>>>>>> enum.
>>>>>>>>>>>
>>>>>>>>>>> Was able to fold together a few specialized operator new()
>>>>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>>>>
>>>>>>>>>>> What do you think now?
>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>>>>
>>>>>>>>>>> Have a nice weekend!
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not
>>>>>>>>>>>>> sure we
>>>>>>>>>>>>> needed yet another.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>>>>>>> version that
>>>>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>>>>>>> aren't even
>>>>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit
>>>>>>>>>>>> older than
>>>>>>>>>>>> that: April 2011. See
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>>>>
>>>>>>>>>>>> and some comments in
>>>>>>>>>>>>
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>>>>
>>>>>>>>>>>> Till then we had avoided any use of C++ std:: stuff -
>>>>>>>>>>>> particularly
>>>>>>>>>>>> anything related to the exception mechanism, which we don't
>>>>>>>>>>>> use at all.
>>>>>>>>>>>>
>>>>>>>>>>>>> any exceptions involved!) but introducing a completely 
>>>>>>>>>>>>> different
>>>>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail
>>>>>>>>>>>>> strategy"
>>>>>>>>>>>>> approach but would like to see this solved holistically,
>>>>>>>>>>>>> replacing
>>>>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>>>>>>> handle all
>>>>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd
>>>>>>>>>>>>> rather not see
>>>>>>>>>>>>> just another point-patch put in place.
>>>>>>>>>>>> The bigger problem is probably still too big to really handle
>>>>>>>>>>>> - so
>>>>>>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>>>>>>> ResourceObj for
>>>>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> For the record I found the original proposal extremely
>>>>>>>>>>>>> confusing:
>>>>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>>> Keith,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...)
>>>>>>>>>>>>>>> function.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>>>>> other than it should be done in a way that's maintainable
>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>> and easily understandable by future generations of hotspot
>>>>>>>>>>>>>>>> developers.
>>>>>>>>>>>>>>>> With this in mind, the only potential solution that I
>>>>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>>>>> using a boolean with naked true/false values as
>>>>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural
>>>>>>>>>>>>>>>> way to do
>>>>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever. 
>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is
>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>>>>>>> simple just
>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>> a new value to use. However if this ends up being
>>>>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we
>>>>>>>>>>>>>>>> can do
>>>>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> - Keith
>>>>>>>
>>>>>

From rkennke at redhat.com  Tue Oct 16 08:01:49 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 16 Oct 2012 17:01:49 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
	<1349988670.1682.16.camel@moonlight>
	<F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>
Message-ID: <1350399709.2097.4.camel@mercury>

Hi Christian,

> >>>> In the recent weeks I worked on the Zero interpreter, to get it to build
> >>>> and run with JDK8, and in particular with the latest changes that came
> >>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> >>>> 
> >>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> >> 
> >> src/share/vm/asm/codeBuffer.cpp:
> >> 
> >> -  if (dest->blob() == NULL) {
> >> +  if (dest->blob() == NULL && dest_filled != 0x0) {
> >> 
> >> Do we really need this when you have this:
> > 
> > The above is needed, because the loop above it that initializes
> > dest_filled is never executed. However, I will change the test to
> > dest_filled != NULL :-)
> > 
> >> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
> >> 
> >> -  memset(to, value, count);
> >> +  if ( count > 0 ) memset(to, value, count);
> >> 
> >> }
> > 
> > Turns out that this is 1. not related to the other change above and 2.
> > not needed. I'll remove it.
> > 
> >> src/share/vm/interpreter/interpreter.cpp:
> >> 
> >> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
> >> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
> >> 
> >> Why did you need that change?
> > 
> > Apparently, before the whole table was initialized, and the methodhandle
> > related entries left as abstract. Now the methodhandle entries are
> > simply left to NULL. I suppose we could change the assert to 
> > 
> > assert(_entry_table[kind] == NULL, "previous value must be NULL");
> > 
> > Alternatively, we could fix the code that puts the other entries to also
> > set the methodhandle entries to AME and go back to the original assert.
> > What do you think?
> 
> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
> 
>   // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
>   for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
>     Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
>     Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
>   }                                                                                                                                                              
> 
> You need similar code in Zero.

Alright, I extracted this piece of code into a separate protected method
void AbstractInterpreterGenerator::initializeMethodHandleEntries() and
call it both from templateInterpreter and cppInterpreter to initialize
the method handle entries to AME.

This new webrev also reverts this:

>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
> >> 
> >> -  memset(to, value, count);
> >> +  if ( count > 0 ) memset(to, value, count);
> >> 
> >> }
> 

.. and changes the 0x0 to NULL here:


>> src/share/vm/asm/codeBuffer.cpp:
> >> 
> >> -  if (dest->blob() == NULL) {
> >> +  if (dest->blob() == NULL && dest_filled != 0x0) {
> >> 
> 

I tried JRuby a little more and verified that it's actually using +indy,
and it works all well.

http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.01/

Is this ok to commit now?

Roman



From christian.thalinger at oracle.com  Tue Oct 16 11:01:04 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Oct 2012 11:01:04 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
Message-ID: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>

http://cr.openjdk.java.net/~twisti/8000989

8000989: smaller code changes to make future JSR 292 backports easier
Reviewed-by:

In 8 we added two new constructors to InternalError which we use in
292.  Factor InternalError generation to a method to make future
backports to 7u easier.

src/share/classes/java/lang/invoke/BoundMethodHandle.java
src/share/classes/java/lang/invoke/CallSite.java
src/share/classes/java/lang/invoke/DirectMethodHandle.java
src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
src/share/classes/java/lang/invoke/Invokers.java
src/share/classes/java/lang/invoke/LambdaForm.java
src/share/classes/java/lang/invoke/MemberName.java
src/share/classes/java/lang/invoke/MethodHandle.java
src/share/classes/java/lang/invoke/MethodHandleImpl.java
src/share/classes/java/lang/invoke/MethodHandleStatics.java
src/share/classes/sun/invoke/util/ValueConversions.java
test/java/lang/invoke/BigArityTest.java
test/java/lang/invoke/PrivateInvokeTest.java


From john.r.rose at oracle.com  Tue Oct 16 11:11:30 2012
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 16 Oct 2012 11:11:30 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
Message-ID: <07B9E251-2802-4E06-BFFC-53744355D331@oracle.com>

Reviewed; good.  This removes a significant source of friction (mismerges) for sharing changes between 7 and 8.  ? John

On Oct 16, 2012, at 11:01 AM, Christian Thalinger wrote:

> http://cr.openjdk.java.net/~twisti/8000989
> 
> 8000989: smaller code changes to make future JSR 292 backports easier
> Reviewed-by:
> 
> In 8 we added two new constructors to InternalError which we use in
> 292.  Factor InternalError generation to a method to make future
> backports to 7u easier.
> 
> src/share/classes/java/lang/invoke/BoundMethodHandle.java
> src/share/classes/java/lang/invoke/CallSite.java
> src/share/classes/java/lang/invoke/DirectMethodHandle.java
> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> src/share/classes/java/lang/invoke/Invokers.java
> src/share/classes/java/lang/invoke/LambdaForm.java
> src/share/classes/java/lang/invoke/MemberName.java
> src/share/classes/java/lang/invoke/MethodHandle.java
> src/share/classes/java/lang/invoke/MethodHandleImpl.java
> src/share/classes/java/lang/invoke/MethodHandleStatics.java
> src/share/classes/sun/invoke/util/ValueConversions.java
> test/java/lang/invoke/BigArityTest.java
> test/java/lang/invoke/PrivateInvokeTest.java
> 


From christian.thalinger at oracle.com  Tue Oct 16 11:20:59 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Oct 2012 11:20:59 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <07B9E251-2802-4E06-BFFC-53744355D331@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
	<07B9E251-2802-4E06-BFFC-53744355D331@oracle.com>
Message-ID: <80363693-6553-4BA1-9CD2-4929D39FFBD9@oracle.com>

Thank you, John.  After this is in 8 I will send a 7 backport webrev.

-- Chris

On Oct 16, 2012, at 11:11 AM, John Rose <john.r.rose at oracle.com> wrote:

> Reviewed; good.  This removes a significant source of friction (mismerges) for sharing changes between 7 and 8.  ? John
> 
> On Oct 16, 2012, at 11:01 AM, Christian Thalinger wrote:
> 
>> http://cr.openjdk.java.net/~twisti/8000989
>> 
>> 8000989: smaller code changes to make future JSR 292 backports easier
>> Reviewed-by:
>> 
>> In 8 we added two new constructors to InternalError which we use in
>> 292.  Factor InternalError generation to a method to make future
>> backports to 7u easier.
>> 
>> src/share/classes/java/lang/invoke/BoundMethodHandle.java
>> src/share/classes/java/lang/invoke/CallSite.java
>> src/share/classes/java/lang/invoke/DirectMethodHandle.java
>> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> src/share/classes/java/lang/invoke/Invokers.java
>> src/share/classes/java/lang/invoke/LambdaForm.java
>> src/share/classes/java/lang/invoke/MemberName.java
>> src/share/classes/java/lang/invoke/MethodHandle.java
>> src/share/classes/java/lang/invoke/MethodHandleImpl.java
>> src/share/classes/java/lang/invoke/MethodHandleStatics.java
>> src/share/classes/sun/invoke/util/ValueConversions.java
>> test/java/lang/invoke/BigArityTest.java
>> test/java/lang/invoke/PrivateInvokeTest.java
>> 
> 


From christian.thalinger at oracle.com  Tue Oct 16 12:54:31 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Oct 2012 12:54:31 -0700
Subject: RFR (S): 8000999: backport of JSR 292 to 7u
Message-ID: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>

http://cr.openjdk.java.net/~twisti/8000999

8000999: backport of JSR 292 to 7u
Reviewed-by:

This is an umbrella bug for these changes (which are backported in one
changeset):

6983728: JSR 292 remove argument count limitations 
7128512: Javadoc typo in java.lang.invoke.MethodHandle 
7117167: Misc warnings in java.lang.invoke and sun.invoke.* 
7129034: VM crash with a field setter method with a filterArguments 
7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited 
7127687: MethodType leaks memory due to interning 
7023639: JSR 292 method handle invocation needs a fast path for compiled code 
7188911: nightly failures after JSR 292 lazy method handle update (round 2) 
7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize 
7191102: nightly failures after JSR 292 lazy method handle update (round 3) 
7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa 
7194662: JSR 292: PermuteArgsTest times out in nightly test runs

The backport is just copying over the files from JDK 8.  That's why the webrev is so big and pretty useless.  The real changes between 8 and 7 are these:

diff -Nur jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java
--- jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java    2012-10-15 12:21:52.806052959 -0700
+++ jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java   2012-10-16 10:48:29.728257304 -0700
@@ -94,10 +94,14 @@
 
     // handy shared exception makers (they simplify the common case code)
     /*non-public*/ static InternalError newInternalError(String message, Throwable cause) {
-        return new InternalError(message, cause);
+        InternalError e = new InternalError(message);
+        e.initCause(cause);
+        return e;
     }
     /*non-public*/ static InternalError newInternalError(Throwable cause) {
-        return new InternalError(cause);
+        InternalError e = new InternalError();
+        e.initCause(cause);
+        return e;
     }
     /*non-public*/ static RuntimeException newIllegalStateException(String message) {
         return new IllegalStateException(message);
diff -Nur jdk8/src/share/classes/sun/invoke/util/ValueConversions.java jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java
--- jdk8/src/share/classes/sun/invoke/util/ValueConversions.java        2012-10-16 10:49:36.081911283 -0700
+++ jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java       2012-10-16 10:48:19.626424849 -0700
@@ -1211,9 +1211,13 @@
 
     // handy shared exception makers (they simplify the common case code)
     private static InternalError newInternalError(String message, Throwable cause) {
-        return new InternalError(message, cause);
+        InternalError e = new InternalError(message);
+        e.initCause(cause);
+        return e;
     }
     private static InternalError newInternalError(Throwable cause) {
-        return new InternalError(cause);
+        InternalError e = new InternalError();
+        e.initCause(cause);
+        return e;
     }
 }
diff --git a/src/share/classes/sun/misc/Unsafe.java b/src/share/classes/sun/misc/Unsafe.java
--- a/src/share/classes/sun/misc/Unsafe.java
+++ b/src/share/classes/sun/misc/Unsafe.java
@@ -678,6 +678,14 @@
     public native Object staticFieldBase(Field f);
 
     /**
+     * Detect if the given class may need to be initialized. This is often
+     * needed in conjunction with obtaining the static field base of a
+     * class.
+     * @return false only if a call to {@code ensureClassInitialized} would have no effect
+     */
+    public native boolean shouldBeInitialized(Class c);
+
+    /**
      * Ensure the given class has been initialized. This is often
      * needed in conjunction with obtaining the static field base of a
      * class.


From david.holmes at oracle.com  Tue Oct 16 18:53:29 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 11:53:29 +1000
Subject: JNI DetachCurrentThread() usage during JVM process exit
In-Reply-To: <507D59CB.4020602@netbauds.net>
References: <507D59CB.4020602@netbauds.net>
Message-ID: <507E0F99.9000900@oracle.com>

Hi Darryl,

On 16/10/2012 10:57 PM, Darryl L. Miles wrote:
> I am trying to understand the reasons why the JNI method
> DetachCurrentThread() blocks the thread in VM_Exit::wait_if_vm_exited()
> instead of returning control back to JNI during process exit proceedings.

The exit procedure tries to bring everything to a quiescent state. The 
thread doing the exit will wait a short while for threads in native to 
try and return into the VM. After that any thread trying to return into 
the VM is simply blocked - if the wait_if_vm_exited didn't do it then 
the state transition to _thread_in_vm would.

> This is particular problematic when the thread in question is actually
> owned by JNI (because it started out life with JNI using
> pthread_create() directly).

That thread is racing with the process being blown away. Even if the 
detach did a quick-exit (without actually detaching - which would 
violate it's specification!) there is absolutely no guarantee that the 
thread would be able to complete any clean up before process 
termination. I think it is more likely that any attempted cleanup would 
be incomplete - which might be worse than not attempting the cleanup at all.

> Sequence of events:
>
> * java.exe starts up
> * JAR loaded and JNI *.so loaded
> * addShutdownHook() thread added
> * application uses/implements JNI based thread pool, this creates a
> thread, that does work, completes and stays idle in pool. During the
> time of doing work it performs a JNI AttachCurrentThreadAsDaemon() so it
> can call into Java. Not all JNI threads created call into Java, they are
> attached to VM on their first invocation into Java and remain attached.
> If the thread pool prunes (terminates) idle workers, those threads will
> call DetachCurrentThread() if they had been attached before the worker
> thread exits.
> * The Application decides to exit, the JNI based thread pool has no
> active threads but may have management thread and one or more workers
> that are idle in the pool.
> * System.exit() is called.
> * addShutdownHook() thread started and run
> * From the shutdownHook thread this instructs the JNI based thread pool
> to close, during this close each worker thread that did an
> 'AttachCurrentThreadAsDaemon()' will perform a 'DetachCurrentThread()'.
> These threads hang because the JVM never returns control back to JNI.

At the time the shutdown hooks are run the exit procedure is still in 
Java code, we haven't called into the VM to do the exit and 
VM_Exit::block_if_vm_exited() will not block. Have you got native stack 
traces showing that the JNI threads are in fact blocked here? Something 
seems amiss.

David
-----

> These threads are owned by JNI (not by Java) so they may have further
> clean up to do and will then exit if the DetachCurrentThread() were to
> return control.
> * The addShutdownHook() thread deadlocks waiting for the JNI thread pool
> to close.
>
>
>
> I can understand if the thread started out life as Java Thread object or
> as an internal house keeping thread (that scenario is unlikely to call
> any of my JNI).
>
> But when the thread started out life from JNI using pthread_create() and
> then was introduced to the JVM, I think that JNI DetachCurrentThread()
> should not block even on exit under these circumstances. If anything the
> DetachCurrentThread() is signalling that Java has no further need to
> worry about this thread anymore, i.e. it can not invoke any Java.
> Obviously I would expect the JVM to refuse any further Attach requests
> under a VM_Exit scenario.
>
> I think JVM thread accounting should handle this case, maybe defer TLS
> cleanup if it is not possible to touch some data due to locking, or just
> never cleanup if the process is going to terminate anyway.
>
>
> TIA,
>
> Darryl
>

From david.holmes at oracle.com  Tue Oct 16 19:18:28 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 12:18:28 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507D5C38.8050409@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
Message-ID: <507E1574.3090507@oracle.com>

On 16/10/2012 11:08 PM, Coleen Phillmore wrote:
>
> Hi, I still disagree.

That's okay, this is completely subjective :)

> On 10/15/2012 8:01 AM, David Holmes wrote:
<snip>
>>
>> But, as I said in my PS email, if all this was rewritten we'd be
>> passing null back for OOM, so adding all this additional policy
>> selection seems to be a step in the wrong direction. A minimal change
>> to ResourceObj along the lines of what exists (std::nothrow) for
>> CHeapObj seems the path of least resistance to me.
>>
>
> Actually to throw OOM, you'd change the throw version of the operator
> new, not the nothrow version. The nothrow version should be just that.

Note I didn't say anything about throwing OOM (OOME really), just 
reporting OOM. Given we don't use C++ exceptions we would have to return 
NULL to indicate an OOM condition.

> My main concern is unintended consequences of hiding or overloading to
> the wrong operator new. There's some code in allocation.cpp that tries
> to catch code that unintentionally uses the global operator new, which
> is disabled. Part of adding the nonstandard overloading operator new
> should be enabling this code with the nothrow version. I think this is
> more additional work.

I don't quite follow that as we already have various custom overloads of 
operator new, but lets not dwell on this part ...

> I think Nils version _03 of this change is really good and they need it
> for JFR now. I don't think we should hold it hostage to this
> disagreement on this issue. I also don't have time to read the rest of
> Scott Meyer's books right now to use his arguments why this is dangerous.

I don't think _03 is inconsistent with my "path of least resistance". :) 
Notwithstanding my preference to not use an Enum (and greater preference 
to use something much shorter named - eg AllocFail rather than 
AllocFailStrategy !)

src/share/vm/memory/allocation.inline.hpp

line 94: throw_constant should be nothrow_constant

But is there any real need to change this to use the updated 
AllocateHeap methods instead of continuing to use os::malloc?

---

src/share/vm/runtime/thread.cpp

   void* Thread::allocate(size_t size, bool throw_excpt, MEMFLAGS flags) {
     if (UseBiasedLocking) {
       const int alignment = markOopDesc::biased_lock_alignment;
       size_t aligned_size = size + (alignment - sizeof(intptr_t));
       void* real_malloc_addr = throw_excpt? AllocateHeap(aligned_size, 
flags, CURRENT_PC)
!                                           : AllocateHeap(aligned_size, 
flags, CURRENT_PC,
! 
AllocFailStrategy::RETURN_NULL);

throw_excpt should be renamed "exit_on_oom".

The allocation logic is simpler, in my opinion, if we simply select the 
OOM policy eg:

void* real_malloc_addr = AllocateHeap(aligned_size, flags, CURRENT_PC,
    (exit_on_oom ? AllocFailStrategy::EXIT_OOM : 
AllocFailStrategy::RETURN_NULL)

Thanks,
David
-------

> Thanks,
> Coleen
>> David
>>
>>> Thanks,
>>> Coleen
>>>
>>> On 10/15/2012 2:49 AM, David Holmes wrote:
>>>> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>>>>
>>>>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>>>>
>>>>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>>>>> So in general we have two competing wishes here:
>>>>>>>
>>>>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>>>>> methods. (basically webrev 03)
>>>>>>> Pros: more c++ standard-ish
>>>>>>> cons: more boiler plate, not descriptive of what actually happens,
>>>>>>> two different mechanisms.
>>>>>>>
>>>>>>>
>>>>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>>>>> pros: more accurate description, cleaner implementation
>>>>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>>>>>>> making up our own stuff.
>>>>>>
>>>>>> I'm less supportive of using an Enum over a boolean now. A
>>>>>> two-valued enum is a boolean. And we are treating it as a boolean
>>>>>> any time we use if-else rather than a switch-style selector - we
>>>>>> couldn't add a third option without revisiting every place it is
>>>>>> currently checked. And I just don't see there being any third option.
>>>>>>
>>>>> Remember that the point of not having a boolean wasn't to enable a
>>>>> potential third option, but to make callsites clearer.
>>>>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>>>>
>>>> Okay, but a bool constant has the same properties (and is used
>>>> elsewhere in the VM).
>>>>
>>>> David
>>>> ------
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I never liked std::nothrow because we never threw in the first
>>>>>> place, but if it had instead been std::return_null I would have been
>>>>>> fine with it. But given we use custom multi-arg variants of operator
>>>>>> new I don't see that the "familiarity"/"standard" argument really
>>>>>> has that much weight. If anything using a standard feature in a
>>>>>> non-standard environment is likely to be more confusing to people
>>>>>> who might naturally expect that if they see a no_throw variant then
>>>>>> the other variant will in fact throw, not abort the VM!
>>>>>>
>>>>>> I have some specific comments on specific changes but there doesn't
>>>>>> seem much point going to that level of discussion yet. Except I will
>>>>>> mention that in thread.cpp the pre-existing throw_excpt argument to
>>>>>> allocate seems to really mean "exit_out_of_memory" and should be
>>>>>> renamed.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> So.. discuss! John, what do you think having seen the different
>>>>>>> implementations? It would be nice to be able to get in any version
>>>>>>> of it so I can develop the feature that will depend on it... :)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nisse
>>>>>>>
>>>>>>> On Oct 12, 2012, at 17:03 , Coleen
>>>>>>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I still prefer webrev 03 to webrev 04. std::nothrow as a parameter
>>>>>>>> means something to any C++ developer and AllocationStrategy::OOM
>>>>>>>> only means something to a hotspot developer. I think we should use
>>>>>>>> the standard C++ apis when possible. The duplication of operator
>>>>>>>> new is not significant. Plus if someone adds new (std::nothrow)
>>>>>>>> call or you forgot to clean up one, it think it will overload to
>>>>>>>> the std::operator new() which could lead to a subtle bug.
>>>>>>>>
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 12 okt 2012 kl. 16:25 skrev Keith
>>>>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>>>>
>>>>>>>>>> May as well lift the allocation fail strategy up into
>>>>>>>>>> Thread::allocate() as well, replacing the boolean parameter
>>>>>>>>>> there.
>>>>>>>>>>
>>>>>>>>> Ah, good idea.
>>>>>>>>>
>>>>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to
>>>>>>>>>> replace it with RETURN_NULL.
>>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>> Argh, darn, you're right of course.
>>>>>>>>>
>>>>>>>>> Will fix.
>>>>>>>>>
>>>>>>>>>> - Keith
>>>>>>>>>>
>>>>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey guys!
>>>>>>>>>>>
>>>>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>>>>> So I got rid of all the instances of std::nothrow throughout
>>>>>>>>>>> the code and replaced them with a new shiny and descriptive
>>>>>>>>>>> enum.
>>>>>>>>>>>
>>>>>>>>>>> Was able to fold together a few specialized operator new()
>>>>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>>>>
>>>>>>>>>>> What do you think now?
>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>>>>
>>>>>>>>>>> Have a nice weekend!
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not
>>>>>>>>>>>>> sure we
>>>>>>>>>>>>> needed yet another.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>>>>>>> version that
>>>>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>>>>>>> aren't even
>>>>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit
>>>>>>>>>>>> older than
>>>>>>>>>>>> that: April 2011. See
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>>>>
>>>>>>>>>>>> and some comments in
>>>>>>>>>>>>
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>>>>
>>>>>>>>>>>> Till then we had avoided any use of C++ std:: stuff -
>>>>>>>>>>>> particularly
>>>>>>>>>>>> anything related to the exception mechanism, which we don't
>>>>>>>>>>>> use at all.
>>>>>>>>>>>>
>>>>>>>>>>>>> any exceptions involved!) but introducing a completely
>>>>>>>>>>>>> different
>>>>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail
>>>>>>>>>>>>> strategy"
>>>>>>>>>>>>> approach but would like to see this solved holistically,
>>>>>>>>>>>>> replacing
>>>>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>>>>>>> handle all
>>>>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd
>>>>>>>>>>>>> rather not see
>>>>>>>>>>>>> just another point-patch put in place.
>>>>>>>>>>>> The bigger problem is probably still too big to really handle
>>>>>>>>>>>> - so
>>>>>>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>>>>>>> ResourceObj for
>>>>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> For the record I found the original proposal extremely
>>>>>>>>>>>>> confusing:
>>>>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>>> Keith,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...)
>>>>>>>>>>>>>>> function.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>>>>> other than it should be done in a way that's maintainable
>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>> and easily understandable by future generations of hotspot
>>>>>>>>>>>>>>>> developers.
>>>>>>>>>>>>>>>> With this in mind, the only potential solution that I
>>>>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>>>>> using a boolean with naked true/false values as
>>>>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural
>>>>>>>>>>>>>>>> way to do
>>>>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever.
>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is
>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>>>>>>> simple just
>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>> a new value to use. However if this ends up being
>>>>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we
>>>>>>>>>>>>>>>> can do
>>>>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> - Keith
>>>>>>>
>>>>>

From david.holmes at oracle.com  Tue Oct 16 20:54:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 13:54:40 +1000
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
Message-ID: <507E2C00.8070001@oracle.com>

Not sure what relevance there is to hotspot :)

Not meaning to be difficult but why not just apply this change to the 7u 
code and use the appropriate constructors? As I general rule (there are 
exceptions eg java.util.concurrent) I don't think the libraries code is 
written to be directly usable in multiple JDK versions.

Or even add a package-private InternalError class that subclasses 
java.lang.InternalError to add the new constructors? (for 7u)

David


On 17/10/2012 4:01 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8000989
>
> 8000989: smaller code changes to make future JSR 292 backports easier
> Reviewed-by:
>
> In 8 we added two new constructors to InternalError which we use in
> 292.  Factor InternalError generation to a method to make future
> backports to 7u easier.
>
> src/share/classes/java/lang/invoke/BoundMethodHandle.java
> src/share/classes/java/lang/invoke/CallSite.java
> src/share/classes/java/lang/invoke/DirectMethodHandle.java
> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> src/share/classes/java/lang/invoke/Invokers.java
> src/share/classes/java/lang/invoke/LambdaForm.java
> src/share/classes/java/lang/invoke/MemberName.java
> src/share/classes/java/lang/invoke/MethodHandle.java
> src/share/classes/java/lang/invoke/MethodHandleImpl.java
> src/share/classes/java/lang/invoke/MethodHandleStatics.java
> src/share/classes/sun/invoke/util/ValueConversions.java
> test/java/lang/invoke/BigArityTest.java
> test/java/lang/invoke/PrivateInvokeTest.java
>

From david.holmes at oracle.com  Tue Oct 16 20:59:10 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 13:59:10 +1000
Subject: RFR (S): 8000999: backport of JSR 292 to 7u
In-Reply-To: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>
References: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>
Message-ID: <507E2D0E.8080100@oracle.com>

Hi Christian,

Is this just a preliminary review request, as actual backport requests 
have to go to the jdk7u-dev mailing list for approval.

And are these all just bug fixes, or are there any API/spec changes 
involved?

David

On 17/10/2012 5:54 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8000999
>
> 8000999: backport of JSR 292 to 7u
> Reviewed-by:
>
> This is an umbrella bug for these changes (which are backported in one
> changeset):
>
> 6983728: JSR 292 remove argument count limitations
> 7128512: Javadoc typo in java.lang.invoke.MethodHandle
> 7117167: Misc warnings in java.lang.invoke and sun.invoke.*
> 7129034: VM crash with a field setter method with a filterArguments
> 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited
> 7127687: MethodType leaks memory due to interning
> 7023639: JSR 292 method handle invocation needs a fast path for compiled code
> 7188911: nightly failures after JSR 292 lazy method handle update (round 2)
> 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize
> 7191102: nightly failures after JSR 292 lazy method handle update (round 3)
> 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa
> 7194662: JSR 292: PermuteArgsTest times out in nightly test runs
>
> The backport is just copying over the files from JDK 8.  That's why the webrev is so big and pretty useless.  The real changes between 8 and 7 are these:
>
> diff -Nur jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java
> --- jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java    2012-10-15 12:21:52.806052959 -0700
> +++ jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java   2012-10-16 10:48:29.728257304 -0700
> @@ -94,10 +94,14 @@
>
>       // handy shared exception makers (they simplify the common case code)
>       /*non-public*/ static InternalError newInternalError(String message, Throwable cause) {
> -        return new InternalError(message, cause);
> +        InternalError e = new InternalError(message);
> +        e.initCause(cause);
> +        return e;
>       }
>       /*non-public*/ static InternalError newInternalError(Throwable cause) {
> -        return new InternalError(cause);
> +        InternalError e = new InternalError();
> +        e.initCause(cause);
> +        return e;
>       }
>       /*non-public*/ static RuntimeException newIllegalStateException(String message) {
>           return new IllegalStateException(message);
> diff -Nur jdk8/src/share/classes/sun/invoke/util/ValueConversions.java jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java
> --- jdk8/src/share/classes/sun/invoke/util/ValueConversions.java        2012-10-16 10:49:36.081911283 -0700
> +++ jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java       2012-10-16 10:48:19.626424849 -0700
> @@ -1211,9 +1211,13 @@
>
>       // handy shared exception makers (they simplify the common case code)
>       private static InternalError newInternalError(String message, Throwable cause) {
> -        return new InternalError(message, cause);
> +        InternalError e = new InternalError(message);
> +        e.initCause(cause);
> +        return e;
>       }
>       private static InternalError newInternalError(Throwable cause) {
> -        return new InternalError(cause);
> +        InternalError e = new InternalError();
> +        e.initCause(cause);
> +        return e;
>       }
>   }
> diff --git a/src/share/classes/sun/misc/Unsafe.java b/src/share/classes/sun/misc/Unsafe.java
> --- a/src/share/classes/sun/misc/Unsafe.java
> +++ b/src/share/classes/sun/misc/Unsafe.java
> @@ -678,6 +678,14 @@
>       public native Object staticFieldBase(Field f);
>
>       /**
> +     * Detect if the given class may need to be initialized. This is often
> +     * needed in conjunction with obtaining the static field base of a
> +     * class.
> +     * @return false only if a call to {@code ensureClassInitialized} would have no effect
> +     */
> +    public native boolean shouldBeInitialized(Class c);
> +
> +    /**
>        * Ensure the given class has been initialized. This is often
>        * needed in conjunction with obtaining the static field base of a
>        * class.
>

From nils.loodin at oracle.com  Wed Oct 17 01:51:04 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Wed, 17 Oct 2012 10:51:04 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507E1574.3090507@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
	<507E1574.3090507@oracle.com>
Message-ID: <507E7178.2090905@oracle.com>

>
> I don't think _03 is inconsistent with my "path of least resistance". :)
> Notwithstanding my preference to not use an Enum (and greater preference
> to use something much shorter named - eg AllocFail rather than
> AllocFailStrategy !)
>

You're wrong, and here's why!
(I'm sorry, it's really subjective, but it sounded so dramatic!)

I think the point of the type safety of enums is a good one here. It 
will keep people from passing in other booleans by mistake.

Regarding the name, I think it's clearer with the purpose of the class 
that it's something to actaully do with a strategy on allocation failure 
in the current name. AllocFail might be a class with all kinds of 
responsibilities :)

Also ponder the actual consequences of the additional eight characters.
It's really not that hard to break lines to fit 80 characters, so the 
upside clearly beats the downside...

Still open for suggestions though!

Any references to 'throw_constant' instead of 'nothrow_constant' is a 
typo and can safely be disregarded!

About direct os::malloc vs a call to AllocateHeap instead:
AllocateHeap contains code for tracing os:malloc. I assumed (and am of 
the oppinion that) the reason there was a 'naked' call to os::malloc 
without any tracing was there wasn't any support in the infrastructure 
to accomodate this before. IE, an outage.

In its place now, is another call to a function that also calls 
os::malloc, with tracking. Also, the 'chain' of allocation-calls now 
ends at the same place, which is tidier and easier to maintain.


Regards,
Nils Loodin

> src/share/vm/memory/allocation.inline.hpp
>
> line 94: throw_constant should be nothrow_constant
>
> But is there any real need to change this to use the updated
> AllocateHeap methods instead of continuing to use os::malloc?
>
> ---
>
> src/share/vm/runtime/thread.cpp
>
>    void* Thread::allocate(size_t size, bool throw_excpt, MEMFLAGS flags) {
>      if (UseBiasedLocking) {
>        const int alignment = markOopDesc::biased_lock_alignment;
>        size_t aligned_size = size + (alignment - sizeof(intptr_t));
>        void* real_malloc_addr = throw_excpt? AllocateHeap(aligned_size,
> flags, CURRENT_PC)
> !                                           : AllocateHeap(aligned_size,
> flags, CURRENT_PC,
> ! AllocFailStrategy::RETURN_NULL);
>
> throw_excpt should be renamed "exit_on_oom".
>
> The allocation logic is simpler, in my opinion, if we simply select the
> OOM policy eg:
>
> void* real_malloc_addr = AllocateHeap(aligned_size, flags, CURRENT_PC,
>     (exit_on_oom ? AllocFailStrategy::EXIT_OOM :
> AllocFailStrategy::RETURN_NULL)
>
> Thanks,
> David
> -------
>
>> Thanks,
>> Coleen
>>> David
>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 10/15/2012 2:49 AM, David Holmes wrote:
>>>>> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>>>>>
>>>>>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>>>>>
>>>>>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>>>>>> So in general we have two competing wishes here:
>>>>>>>>
>>>>>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>>>>>> methods. (basically webrev 03)
>>>>>>>> Pros: more c++ standard-ish
>>>>>>>> cons: more boiler plate, not descriptive of what actually happens,
>>>>>>>> two different mechanisms.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>>>>>> pros: more accurate description, cleaner implementation
>>>>>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>>>>>>>> making up our own stuff.
>>>>>>>
>>>>>>> I'm less supportive of using an Enum over a boolean now. A
>>>>>>> two-valued enum is a boolean. And we are treating it as a boolean
>>>>>>> any time we use if-else rather than a switch-style selector - we
>>>>>>> couldn't add a third option without revisiting every place it is
>>>>>>> currently checked. And I just don't see there being any third
>>>>>>> option.
>>>>>>>
>>>>>> Remember that the point of not having a boolean wasn't to enable a
>>>>>> potential third option, but to make callsites clearer.
>>>>>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>>>>>
>>>>> Okay, but a bool constant has the same properties (and is used
>>>>> elsewhere in the VM).
>>>>>
>>>>> David
>>>>> ------
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I never liked std::nothrow because we never threw in the first
>>>>>>> place, but if it had instead been std::return_null I would have been
>>>>>>> fine with it. But given we use custom multi-arg variants of operator
>>>>>>> new I don't see that the "familiarity"/"standard" argument really
>>>>>>> has that much weight. If anything using a standard feature in a
>>>>>>> non-standard environment is likely to be more confusing to people
>>>>>>> who might naturally expect that if they see a no_throw variant then
>>>>>>> the other variant will in fact throw, not abort the VM!
>>>>>>>
>>>>>>> I have some specific comments on specific changes but there doesn't
>>>>>>> seem much point going to that level of discussion yet. Except I will
>>>>>>> mention that in thread.cpp the pre-existing throw_excpt argument to
>>>>>>> allocate seems to really mean "exit_out_of_memory" and should be
>>>>>>> renamed.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> So.. discuss! John, what do you think having seen the different
>>>>>>>> implementations? It would be nice to be able to get in any version
>>>>>>>> of it so I can develop the feature that will depend on it... :)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nisse
>>>>>>>>
>>>>>>>> On Oct 12, 2012, at 17:03 , Coleen
>>>>>>>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I still prefer webrev 03 to webrev 04. std::nothrow as a parameter
>>>>>>>>> means something to any C++ developer and AllocationStrategy::OOM
>>>>>>>>> only means something to a hotspot developer. I think we should use
>>>>>>>>> the standard C++ apis when possible. The duplication of operator
>>>>>>>>> new is not significant. Plus if someone adds new (std::nothrow)
>>>>>>>>> call or you forgot to clean up one, it think it will overload to
>>>>>>>>> the std::operator new() which could lead to a subtle bug.
>>>>>>>>>
>>>>>>>>> Coleen
>>>>>>>>>
>>>>>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 12 okt 2012 kl. 16:25 skrev Keith
>>>>>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>>>>>
>>>>>>>>>>> May as well lift the allocation fail strategy up into
>>>>>>>>>>> Thread::allocate() as well, replacing the boolean parameter
>>>>>>>>>>> there.
>>>>>>>>>>>
>>>>>>>>>> Ah, good idea.
>>>>>>>>>>
>>>>>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you want to
>>>>>>>>>>> replace it with RETURN_NULL.
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>> Argh, darn, you're right of course.
>>>>>>>>>>
>>>>>>>>>> Will fix.
>>>>>>>>>>
>>>>>>>>>>> - Keith
>>>>>>>>>>>
>>>>>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey guys!
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>>>>>> So I got rid of all the instances of std::nothrow throughout
>>>>>>>>>>>> the code and replaced them with a new shiny and descriptive
>>>>>>>>>>>> enum.
>>>>>>>>>>>>
>>>>>>>>>>>> Was able to fold together a few specialized operator new()
>>>>>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think now?
>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>>>>>
>>>>>>>>>>>> Have a nice weekend!
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not
>>>>>>>>>>>>>> sure we
>>>>>>>>>>>>>> needed yet another.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>>>>>>>> version that
>>>>>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>>>>>>>> aren't even
>>>>>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit
>>>>>>>>>>>>> older than
>>>>>>>>>>>>> that: April 2011. See
>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>>>>>
>>>>>>>>>>>>> and some comments in
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>>>>>
>>>>>>>>>>>>> Till then we had avoided any use of C++ std:: stuff -
>>>>>>>>>>>>> particularly
>>>>>>>>>>>>> anything related to the exception mechanism, which we don't
>>>>>>>>>>>>> use at all.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> any exceptions involved!) but introducing a completely
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail
>>>>>>>>>>>>>> strategy"
>>>>>>>>>>>>>> approach but would like to see this solved holistically,
>>>>>>>>>>>>>> replacing
>>>>>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>>>>>>>> handle all
>>>>>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd
>>>>>>>>>>>>>> rather not see
>>>>>>>>>>>>>> just another point-patch put in place.
>>>>>>>>>>>>> The bigger problem is probably still too big to really handle
>>>>>>>>>>>>> - so
>>>>>>>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>>>>>>>> ResourceObj for
>>>>>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> For the record I found the original proposal extremely
>>>>>>>>>>>>>> confusing:
>>>>>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>>>> Keith,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...)
>>>>>>>>>>>>>>>> function.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>>>>>> other than it should be done in a way that's maintainable
>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>> and easily understandable by future generations of hotspot
>>>>>>>>>>>>>>>>> developers.
>>>>>>>>>>>>>>>>> With this in mind, the only potential solution that I
>>>>>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>>>>>> using a boolean with naked true/false values as
>>>>>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the natural
>>>>>>>>>>>>>>>>> way to do
>>>>>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever.
>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is
>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>>>>>>>> simple just
>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>> a new value to use. However if this ends up being
>>>>>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>>>>>> this is not the normal use of std::notype_t, then fine, we
>>>>>>>>>>>>>>>>> can do
>>>>>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> - Keith
>>>>>>>>
>>>>>>


From david.holmes at oracle.com  Wed Oct 17 03:50:41 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 20:50:41 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507E7178.2090905@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
	<507E1574.3090507@oracle.com> <507E7178.2090905@oracle.com>
Message-ID: <507E8D81.7010407@oracle.com>

On 17/10/2012 6:51 PM, Nils Loodin wrote:
>> I don't think _03 is inconsistent with my "path of least resistance". :)
>> Notwithstanding my preference to not use an Enum (and greater preference
>> to use something much shorter named - eg AllocFail rather than
>> AllocFailStrategy !)
>>
>
> You're wrong, and here's why!
> (I'm sorry, it's really subjective, but it sounded so dramatic!)
>
> I think the point of the type safety of enums is a good one here. It
> will keep people from passing in other booleans by mistake.

Fine. I think it is overkill. :)

> Regarding the name, I think it's clearer with the purpose of the class
> that it's something to actaully do with a strategy on allocation failure
> in the current name. AllocFail might be a class with all kinds of
> responsibilities :)
>
> Also ponder the actual consequences of the additional eight characters.
> It's really not that hard to break lines to fit 80 characters, so the
> upside clearly beats the downside...
>
> Still open for suggestions though!

Well the important characters are the EXIT_OOM and RETURN_NULL, so when 
the prefix is longer than the real information I consider that 
unnecessary noise. Even no_throw is just std::no_throw not 
AllocationFailureStrategy::no_throw ;-)

> Any references to 'throw_constant' instead of 'nothrow_constant' is a
> typo and can safely be disregarded!
>
> About direct os::malloc vs a call to AllocateHeap instead:
> AllocateHeap contains code for tracing os:malloc. I assumed (and am of
> the oppinion that) the reason there was a 'naked' call to os::malloc
> without any tracing was there wasn't any support in the infrastructure
> to accomodate this before. IE, an outage.

Ummm there is tracing of the malloc calls:

  94     void* p = os::malloc(size, F, (caller_pc != 0 ? caller_pc : 
CALLER_PC));

  95     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);

> In its place now, is another call to a function that also calls
> os::malloc, with tracking. Also, the 'chain' of allocation-calls now
> ends at the same place, which is tidier and easier to maintain.

Well now you end up with two traces per malloc call - but we already had 
that for some of the alloc paths anyway. Though if every path ends in 
AllocateHeap there's no really no reason to add AllocateHeap to the 
trace output.

David
-----

>
>
> Regards,
> Nils Loodin
>
>> src/share/vm/memory/allocation.inline.hpp
>>
>> line 94: throw_constant should be nothrow_constant
>>
>> But is there any real need to change this to use the updated
>> AllocateHeap methods instead of continuing to use os::malloc?
>>
>> ---
>>
>> src/share/vm/runtime/thread.cpp
>>
>> void* Thread::allocate(size_t size, bool throw_excpt, MEMFLAGS flags) {
>> if (UseBiasedLocking) {
>> const int alignment = markOopDesc::biased_lock_alignment;
>> size_t aligned_size = size + (alignment - sizeof(intptr_t));
>> void* real_malloc_addr = throw_excpt? AllocateHeap(aligned_size,
>> flags, CURRENT_PC)
>> ! : AllocateHeap(aligned_size,
>> flags, CURRENT_PC,
>> ! AllocFailStrategy::RETURN_NULL);
>>
>> throw_excpt should be renamed "exit_on_oom".
>>
>> The allocation logic is simpler, in my opinion, if we simply select the
>> OOM policy eg:
>>
>> void* real_malloc_addr = AllocateHeap(aligned_size, flags, CURRENT_PC,
>> (exit_on_oom ? AllocFailStrategy::EXIT_OOM :
>> AllocFailStrategy::RETURN_NULL)
>>
>> Thanks,
>> David
>> -------
>>
>>> Thanks,
>>> Coleen
>>>> David
>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 10/15/2012 2:49 AM, David Holmes wrote:
>>>>>> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>>>>>>
>>>>>>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>>>>>>
>>>>>>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>>>>>>> So in general we have two competing wishes here:
>>>>>>>>>
>>>>>>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>>>>>>> methods. (basically webrev 03)
>>>>>>>>> Pros: more c++ standard-ish
>>>>>>>>> cons: more boiler plate, not descriptive of what actually happens,
>>>>>>>>> two different mechanisms.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>>>>>>> pros: more accurate description, cleaner implementation
>>>>>>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>>>>>>>>> making up our own stuff.
>>>>>>>>
>>>>>>>> I'm less supportive of using an Enum over a boolean now. A
>>>>>>>> two-valued enum is a boolean. And we are treating it as a boolean
>>>>>>>> any time we use if-else rather than a switch-style selector - we
>>>>>>>> couldn't add a third option without revisiting every place it is
>>>>>>>> currently checked. And I just don't see there being any third
>>>>>>>> option.
>>>>>>>>
>>>>>>> Remember that the point of not having a boolean wasn't to enable a
>>>>>>> potential third option, but to make callsites clearer.
>>>>>>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>>>>>>
>>>>>> Okay, but a bool constant has the same properties (and is used
>>>>>> elsewhere in the VM).
>>>>>>
>>>>>> David
>>>>>> ------
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I never liked std::nothrow because we never threw in the first
>>>>>>>> place, but if it had instead been std::return_null I would have
>>>>>>>> been
>>>>>>>> fine with it. But given we use custom multi-arg variants of
>>>>>>>> operator
>>>>>>>> new I don't see that the "familiarity"/"standard" argument really
>>>>>>>> has that much weight. If anything using a standard feature in a
>>>>>>>> non-standard environment is likely to be more confusing to people
>>>>>>>> who might naturally expect that if they see a no_throw variant then
>>>>>>>> the other variant will in fact throw, not abort the VM!
>>>>>>>>
>>>>>>>> I have some specific comments on specific changes but there doesn't
>>>>>>>> seem much point going to that level of discussion yet. Except I
>>>>>>>> will
>>>>>>>> mention that in thread.cpp the pre-existing throw_excpt argument to
>>>>>>>> allocate seems to really mean "exit_out_of_memory" and should be
>>>>>>>> renamed.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> So.. discuss! John, what do you think having seen the different
>>>>>>>>> implementations? It would be nice to be able to get in any version
>>>>>>>>> of it so I can develop the feature that will depend on it... :)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Nisse
>>>>>>>>>
>>>>>>>>> On Oct 12, 2012, at 17:03 , Coleen
>>>>>>>>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I still prefer webrev 03 to webrev 04. std::nothrow as a
>>>>>>>>>> parameter
>>>>>>>>>> means something to any C++ developer and AllocationStrategy::OOM
>>>>>>>>>> only means something to a hotspot developer. I think we should
>>>>>>>>>> use
>>>>>>>>>> the standard C++ apis when possible. The duplication of operator
>>>>>>>>>> new is not significant. Plus if someone adds new (std::nothrow)
>>>>>>>>>> call or you forgot to clean up one, it think it will overload to
>>>>>>>>>> the std::operator new() which could lead to a subtle bug.
>>>>>>>>>>
>>>>>>>>>> Coleen
>>>>>>>>>>
>>>>>>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 12 okt 2012 kl. 16:25 skrev Keith
>>>>>>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>>>>>>
>>>>>>>>>>>> May as well lift the allocation fail strategy up into
>>>>>>>>>>>> Thread::allocate() as well, replacing the boolean parameter
>>>>>>>>>>>> there.
>>>>>>>>>>>>
>>>>>>>>>>> Ah, good idea.
>>>>>>>>>>>
>>>>>>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>>>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you
>>>>>>>>>>>> want to
>>>>>>>>>>>> replace it with RETURN_NULL.
>>>>>>>>>>>>
>>>>>>>>>>>> -
>>>>>>>>>>> Argh, darn, you're right of course.
>>>>>>>>>>>
>>>>>>>>>>> Will fix.
>>>>>>>>>>>
>>>>>>>>>>>> - Keith
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey guys!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>>>>>>> So I got rid of all the instances of std::nothrow throughout
>>>>>>>>>>>>> the code and replaced them with a new shiny and descriptive
>>>>>>>>>>>>> enum.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Was able to fold together a few specialized operator new()
>>>>>>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you think now?
>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Have a nice weekend!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not
>>>>>>>>>>>>>>> sure we
>>>>>>>>>>>>>>> needed yet another.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>>>>>>>>> version that
>>>>>>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>>>>>>>>> aren't even
>>>>>>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit
>>>>>>>>>>>>>> older than
>>>>>>>>>>>>>> that: April 2011. See
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and some comments in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Till then we had avoided any use of C++ std:: stuff -
>>>>>>>>>>>>>> particularly
>>>>>>>>>>>>>> anything related to the exception mechanism, which we don't
>>>>>>>>>>>>>> use at all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> any exceptions involved!) but introducing a completely
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc fail
>>>>>>>>>>>>>>> strategy"
>>>>>>>>>>>>>>> approach but would like to see this solved holistically,
>>>>>>>>>>>>>>> replacing
>>>>>>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>>>>>>>>> handle all
>>>>>>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd
>>>>>>>>>>>>>>> rather not see
>>>>>>>>>>>>>>> just another point-patch put in place.
>>>>>>>>>>>>>> The bigger problem is probably still too big to really handle
>>>>>>>>>>>>>> - so
>>>>>>>>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>>>>>>>>> ResourceObj for
>>>>>>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For the record I found the original proposal extremely
>>>>>>>>>>>>>>> confusing:
>>>>>>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>>>>> Keith,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Personally, I would prefer explicit AllocWithoutThrow(...)
>>>>>>>>>>>>>>>>> function.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>>>>>>> other than it should be done in a way that's maintainable
>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>>> and easily understandable by future generations of
>>>>>>>>>>>>>>>>>> hotspot
>>>>>>>>>>>>>>>>>> developers.
>>>>>>>>>>>>>>>>>> With this in mind, the only potential solution that I
>>>>>>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>>>>>>> using a boolean with naked true/false values as
>>>>>>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the
>>>>>>>>>>>>>>>>>> natural
>>>>>>>>>>>>>>>>>> way to do
>>>>>>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever.
>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is
>>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>>>>>>>>> simple just
>>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>> a new value to use. However if this ends up being
>>>>>>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>>>>>>> this is not the normal use of std::notype_t, then
>>>>>>>>>>>>>>>>>> fine, we
>>>>>>>>>>>>>>>>>> can do
>>>>>>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> - Keith
>>>>>>>>>
>>>>>>>
>

From nils.loodin at oracle.com  Wed Oct 17 04:11:48 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Wed, 17 Oct 2012 13:11:48 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507E8D81.7010407@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
	<507E1574.3090507@oracle.com> <507E7178.2090905@oracle.com>
	<507E8D81.7010407@oracle.com>
Message-ID: <507E9274.6010703@oracle.com>


>
>> Any references to 'throw_constant' instead of 'nothrow_constant' is a
>> typo and can safely be disregarded!
>>

Well, I'm open for a name-discussion anyway :)


>
> Ummm there is tracing of the malloc calls:
>
>   94     void* p = os::malloc(size, F, (caller_pc != 0 ? caller_pc :
> CALLER_PC));
>
>   95     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);


That was from allocation.inline.hpp and is hidden behind an #ifdef 
ASSERT. the #elseif is

  return os::malloc(size, F, (caller_pc != 0 ? caller_pc : CALLER_PC));  ..

Also in thread.cpp there is no tracing, just an os:malloc:

      return throw_excpt? AllocateHeap(size, flags, CURRENT_PC)
-                       : os::malloc(size, flags, CURRENT_PC);
+                       : AllocateHeap(size, flags, CURRENT_PC,
AllocFailStrategy::RETURN_NULL);

So I wouldn't say that these os::malloc calls contain tracing...
Regards,
Nils Loodin

From david.holmes at oracle.com  Wed Oct 17 04:25:14 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 21:25:14 +1000
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507E9274.6010703@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
	<507E1574.3090507@oracle.com> <507E7178.2090905@oracle.com>
	<507E8D81.7010407@oracle.com> <507E9274.6010703@oracle.com>
Message-ID: <507E959A.20706@oracle.com>

On 17/10/2012 9:11 PM, Nils Loodin wrote:
>> Ummm there is tracing of the malloc calls:
>>
>> 94 void* p = os::malloc(size, F, (caller_pc != 0 ? caller_pc :
>> CALLER_PC));
>>
>> 95 if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
>
>
> That was from allocation.inline.hpp and is hidden behind an #ifdef
> ASSERT. the #elseif is

Yes but that was the file I was referring to.

>
> return os::malloc(size, F, (caller_pc != 0 ? caller_pc : CALLER_PC)); ..

And the tracing in AllocateHeap is also guarded by #ifdef ASSERT

  50 // allocate using malloc; will fail if no memory available
   51 inline char* AllocateHeap(size_t size, MEMFLAGS flags, address pc = 0,
   52     AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) {
   53   if (pc == 0) {
   54     pc = CURRENT_PC;
   55   }
   56   char* p = (char*) os::malloc(size, flags, pc);
   57   #ifdef ASSERT
   58   if (PrintMallocFree) trace_heap_malloc(size, "AllocateHeap", p);
   59   #endif

PrintMallocFree in a notProduct flag.

> Also in thread.cpp there is no tracing, just an os:malloc:

And I made no comment in regard to tracing for that file.

David
-----

> return throw_excpt? AllocateHeap(size, flags, CURRENT_PC)
> - : os::malloc(size, flags, CURRENT_PC);
> + : AllocateHeap(size, flags, CURRENT_PC,
> AllocFailStrategy::RETURN_NULL);
>
> So I wouldn't say that these os::malloc calls contain tracing...
> Regards,
> Nils Loodin

From coleen.phillimore at oracle.com  Wed Oct 17 04:39:44 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 17 Oct 2012 07:39:44 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507E7178.2090905@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<CAHjP37F1PddC=uHrebN9+KNOMhCr7Yu96nLG1DLCmWes=K2eYw@mail.gmail.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
	<507E1574.3090507@oracle.com> <507E7178.2090905@oracle.com>
Message-ID: <507E9900.1060309@oracle.com>

On 10/17/2012 4:51 AM, Nils Loodin wrote:
>>
>> I don't think _03 is inconsistent with my "path of least resistance". :)
>> Notwithstanding my preference to not use an Enum (and greater preference
>> to use something much shorter named - eg AllocFail rather than
>> AllocFailStrategy !)
>>
>
> You're wrong, and here's why!
> (I'm sorry, it's really subjective, but it sounded so dramatic!)

:)
>
> I think the point of the type safety of enums is a good one here. It 
> will keep people from passing in other booleans by mistake.

I prefer the enum too.   You cannot pass a naked "true" or "false" to 
this, making the person reading this code go to the function to see what 
it means.   The enum does both documentation and type checking at the 
call site.
>
> Regarding the name, I think it's clearer with the purpose of the class 
> that it's something to actaully do with a strategy on allocation 
> failure in the current name. AllocFail might be a class with all kinds 
> of responsibilities :)
>
> Also ponder the actual consequences of the additional eight characters.
> It's really not that hard to break lines to fit 80 characters, so the 
> upside clearly beats the downside...
>
> Still open for suggestions though!
>
> Any references to 'throw_constant' instead of 'nothrow_constant' is a 
> typo and can safely be disregarded!
>

Does this even need a parameter name?

Karen, Keith and I were talking about this yesterday.   Can you revert 
the change in thread.cpp?
> About direct os::malloc vs a call to AllocateHeap instead:
> AllocateHeap contains code for tracing os:malloc. I assumed (and am of 
> the oppinion that) the reason there was a 'naked' call to os::malloc 
> without any tracing was there wasn't any support in the infrastructure 
> to accomodate this before. IE, an outage.

Yes, this is exactly why there are os::malloc calls in the code.   There 
was never a nothrow new.   A future cleanup would be to make the 
os::malloc private except to the "new" calls, and purge the remaining 
os::malloc calls (if possible).   Not as part of this bug fix.

>
> In its place now, is another call to a function that also calls 
> os::malloc, with tracking. Also, the 'chain' of allocation-calls now 
> ends at the same place, which is tidier and easier to maintain.
>

Yes, and they rely on stack depth for native memory tracking.

Coleen
>
> Regards,
> Nils Loodin
>
>> src/share/vm/memory/allocation.inline.hpp
>>
>> line 94: throw_constant should be nothrow_constant
>>
>> But is there any real need to change this to use the updated
>> AllocateHeap methods instead of continuing to use os::malloc?
>>
>> ---
>>
>> src/share/vm/runtime/thread.cpp
>>
>>    void* Thread::allocate(size_t size, bool throw_excpt, MEMFLAGS 
>> flags) {
>>      if (UseBiasedLocking) {
>>        const int alignment = markOopDesc::biased_lock_alignment;
>>        size_t aligned_size = size + (alignment - sizeof(intptr_t));
>>        void* real_malloc_addr = throw_excpt? AllocateHeap(aligned_size,
>> flags, CURRENT_PC)
>> !                                           : AllocateHeap(aligned_size,
>> flags, CURRENT_PC,
>> ! AllocFailStrategy::RETURN_NULL);
>>
>> throw_excpt should be renamed "exit_on_oom".
>>
>> The allocation logic is simpler, in my opinion, if we simply select the
>> OOM policy eg:
>>
>> void* real_malloc_addr = AllocateHeap(aligned_size, flags, CURRENT_PC,
>>     (exit_on_oom ? AllocFailStrategy::EXIT_OOM :
>> AllocFailStrategy::RETURN_NULL)
>>
>> Thanks,
>> David
>> -------
>>
>>> Thanks,
>>> Coleen
>>>> David
>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 10/15/2012 2:49 AM, David Holmes wrote:
>>>>>> On 15/10/2012 4:29 PM, Nils Loodin wrote:
>>>>>>>
>>>>>>> On Oct 15, 2012, at 01:10 , David Holmes wrote:
>>>>>>>
>>>>>>>> On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>>>>>>> So in general we have two competing wishes here:
>>>>>>>>>
>>>>>>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>>>>>>> methods. (basically webrev 03)
>>>>>>>>> Pros: more c++ standard-ish
>>>>>>>>> cons: more boiler plate, not descriptive of what actually 
>>>>>>>>> happens,
>>>>>>>>> two different mechanisms.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>>>>>>> pros: more accurate description, cleaner implementation
>>>>>>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're
>>>>>>>>> making up our own stuff.
>>>>>>>>
>>>>>>>> I'm less supportive of using an Enum over a boolean now. A
>>>>>>>> two-valued enum is a boolean. And we are treating it as a boolean
>>>>>>>> any time we use if-else rather than a switch-style selector - we
>>>>>>>> couldn't add a third option without revisiting every place it is
>>>>>>>> currently checked. And I just don't see there being any third
>>>>>>>> option.
>>>>>>>>
>>>>>>> Remember that the point of not having a boolean wasn't to enable a
>>>>>>> potential third option, but to make callsites clearer.
>>>>>>> Alloc(size, false) is less descriptive than Alloc(size, no_throw).
>>>>>>
>>>>>> Okay, but a bool constant has the same properties (and is used
>>>>>> elsewhere in the VM).
>>>>>>
>>>>>> David
>>>>>> ------
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I never liked std::nothrow because we never threw in the first
>>>>>>>> place, but if it had instead been std::return_null I would have 
>>>>>>>> been
>>>>>>>> fine with it. But given we use custom multi-arg variants of 
>>>>>>>> operator
>>>>>>>> new I don't see that the "familiarity"/"standard" argument really
>>>>>>>> has that much weight. If anything using a standard feature in a
>>>>>>>> non-standard environment is likely to be more confusing to people
>>>>>>>> who might naturally expect that if they see a no_throw variant 
>>>>>>>> then
>>>>>>>> the other variant will in fact throw, not abort the VM!
>>>>>>>>
>>>>>>>> I have some specific comments on specific changes but there 
>>>>>>>> doesn't
>>>>>>>> seem much point going to that level of discussion yet. Except I 
>>>>>>>> will
>>>>>>>> mention that in thread.cpp the pre-existing throw_excpt 
>>>>>>>> argument to
>>>>>>>> allocate seems to really mean "exit_out_of_memory" and should be
>>>>>>>> renamed.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> So.. discuss! John, what do you think having seen the different
>>>>>>>>> implementations? It would be nice to be able to get in any 
>>>>>>>>> version
>>>>>>>>> of it so I can develop the feature that will depend on it... :)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Nisse
>>>>>>>>>
>>>>>>>>> On Oct 12, 2012, at 17:03 , Coleen
>>>>>>>>> Phillimore<coleen.phillimore at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I still prefer webrev 03 to webrev 04. std::nothrow as a 
>>>>>>>>>> parameter
>>>>>>>>>> means something to any C++ developer and AllocationStrategy::OOM
>>>>>>>>>> only means something to a hotspot developer. I think we 
>>>>>>>>>> should use
>>>>>>>>>> the standard C++ apis when possible. The duplication of operator
>>>>>>>>>> new is not significant. Plus if someone adds new (std::nothrow)
>>>>>>>>>> call or you forgot to clean up one, it think it will overload to
>>>>>>>>>> the std::operator new() which could lead to a subtle bug.
>>>>>>>>>>
>>>>>>>>>> Coleen
>>>>>>>>>>
>>>>>>>>>> On 10/12/2012 10:40 AM, Nils Loodin wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 12 okt 2012 kl. 16:25 skrev Keith
>>>>>>>>>>> McGuigan<keith.mcguigan at oracle.com>:
>>>>>>>>>>>
>>>>>>>>>>>> May as well lift the allocation fail strategy up into
>>>>>>>>>>>> Thread::allocate() as well, replacing the boolean parameter
>>>>>>>>>>>> there.
>>>>>>>>>>>>
>>>>>>>>>>> Ah, good idea.
>>>>>>>>>>>
>>>>>>>>>>>> I think you're replacements of new(std::nothrow) XXX() wit new
>>>>>>>>>>>> (EXIT_OOM) XXX() are all reversed: if it was nothrow you 
>>>>>>>>>>>> want to
>>>>>>>>>>>> replace it with RETURN_NULL.
>>>>>>>>>>>>
>>>>>>>>>>>> -
>>>>>>>>>>> Argh, darn, you're right of course.
>>>>>>>>>>>
>>>>>>>>>>> Will fix.
>>>>>>>>>>>
>>>>>>>>>>>> - Keith
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 12, 2012, at 9:14 AM, Nils Loodin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey guys!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for yet another round of informative code reviews!
>>>>>>>>>>>>> So I got rid of all the instances of std::nothrow throughout
>>>>>>>>>>>>> the code and replaced them with a new shiny and descriptive
>>>>>>>>>>>>> enum.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Was able to fold together a few specialized operator new()
>>>>>>>>>>>>> because of it, with more shared code as a result.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you think now?
>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.04/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Have a nice weekend!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/12/2012 06:47 AM, David Holmes wrote:
>>>>>>>>>>>>>> On 12/10/2012 2:21 PM, David Holmes wrote:
>>>>>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are a number of existing bugs/RFEs in this area - not
>>>>>>>>>>>>>>> sure we
>>>>>>>>>>>>>>> needed yet another.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>>>>>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your comments on this issue are great! So here's another
>>>>>>>>>>>>>>>> version that
>>>>>>>>>>>>>>>> uses an enum instead of std::nothrow_t trickery!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>>>>>>>>>>>>>>> I dislike the std::nothrow usage that NMT introduced (there
>>>>>>>>>>>>>>> aren't even
>>>>>>>>>>>>>> Apologies it wasn't NMT that introduced this - it is a bit
>>>>>>>>>>>>>> older than
>>>>>>>>>>>>>> that: April 2011. See
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7036747
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and some comments in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-4719004
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Till then we had avoided any use of C++ std:: stuff -
>>>>>>>>>>>>>> particularly
>>>>>>>>>>>>>> anything related to the exception mechanism, which we don't
>>>>>>>>>>>>>> use at all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> any exceptions involved!) but introducing a completely
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> mechanism seems counter-productive. I prefer the "alloc 
>>>>>>>>>>>>>>> fail
>>>>>>>>>>>>>>> strategy"
>>>>>>>>>>>>>>> approach but would like to see this solved holistically,
>>>>>>>>>>>>>>> replacing
>>>>>>>>>>>>>>> std::nothrow. Given there exist bigger RFE's to have the VM
>>>>>>>>>>>>>>> handle all
>>>>>>>>>>>>>>> OOM situations gracefully rather than just aborting, I'd
>>>>>>>>>>>>>>> rather not see
>>>>>>>>>>>>>>> just another point-patch put in place.
>>>>>>>>>>>>>> The bigger problem is probably still too big to really 
>>>>>>>>>>>>>> handle
>>>>>>>>>>>>>> - so
>>>>>>>>>>>>>> either copy what we already introduced for CHeapObj to
>>>>>>>>>>>>>> ResourceObj for
>>>>>>>>>>>>>> consistency, or replace both with something better.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For the record I found the original proposal extremely
>>>>>>>>>>>>>>> confusing:
>>>>>>>>>>>>>>> nothrow_constant vs throw_constant.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Nils Loodin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>>>>> Keith,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Personally, I would prefer explicit 
>>>>>>>>>>>>>>>>> AllocWithoutThrow(...)
>>>>>>>>>>>>>>>>> function.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>>>>>>>>>>>>>>> Personally, I don't have strong feelings on how this is
>>>>>>>>>>>>>>>>>> implemented,
>>>>>>>>>>>>>>>>>> other than it should be done in a way that's 
>>>>>>>>>>>>>>>>>> maintainable
>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>>> and easily understandable by future generations of 
>>>>>>>>>>>>>>>>>> hotspot
>>>>>>>>>>>>>>>>>> developers.
>>>>>>>>>>>>>>>>>> With this in mind, the only potential solution that I
>>>>>>>>>>>>>>>>>> don't like is
>>>>>>>>>>>>>>>>>> using a boolean with naked true/false values as
>>>>>>>>>>>>>>>>>> discriminators.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Using some sort of "failure mode" parameter is the 
>>>>>>>>>>>>>>>>>> natural
>>>>>>>>>>>>>>>>>> way to do
>>>>>>>>>>>>>>>>>> this, whether it be enums, std::nothrow_t, or whatever.
>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>> std::nothrow_t already has a type and one value, and is
>>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>>>>> in the few places we're interested in, it seemed easy to
>>>>>>>>>>>>>>>>>> simple just
>>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>> a new value to use. However if this ends up being
>>>>>>>>>>>>>>>>>> confusing because
>>>>>>>>>>>>>>>>>> this is not the normal use of std::notype_t, then 
>>>>>>>>>>>>>>>>>> fine, we
>>>>>>>>>>>>>>>>>> can do
>>>>>>>>>>>>>>>>>> something else.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>> - Keith
>>>>>>>>>
>>>>>>>
>


From coleen.phillimore at oracle.com  Wed Oct 17 08:25:49 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 17 Oct 2012 11:25:49 -0400
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507E9900.1060309@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
	<507E1574.3090507@oracle.com> <507E7178.2090905@oracle.com>
	<507E9900.1060309@oracle.com>
Message-ID: <507ECDFD.6080702@oracle.com>



On 10/17/2012 7:39 AM, Coleen Phillimore wrote:
> Karen, Keith and I were talking about this yesterday.   Can you revert 
> the change in thread.cpp? 

I meant thread.hpp but the answer is no, the parameter list needed a 
const std::nothrow& to match the rest.
Coleen

From christian.thalinger at oracle.com  Wed Oct 17 08:40:59 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 08:40:59 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <507E2C00.8070001@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
	<507E2C00.8070001@oracle.com>
Message-ID: <AB690D9F-180C-4978-B024-DA6DB8E39959@oracle.com>


On Oct 16, 2012, at 8:54 PM, David Holmes <david.holmes at oracle.com> wrote:

> Not sure what relevance there is to hotspot :)

I don't expect anyone from the core library team to actually review these changes :-)

> 
> Not meaning to be difficult but why not just apply this change to the 7u code and use the appropriate constructors? As I general rule (there are exceptions eg java.util.concurrent) I don't think the libraries code is written to be directly usable in multiple JDK versions.

It's not about running in different JDK versions.  It's about keeping the merging effort to a minimum when we back port future performance work.

-- Chris

> 
> Or even add a package-private InternalError class that subclasses java.lang.InternalError to add the new constructors? (for 7u)
> 
> David
> 
> 
> On 17/10/2012 4:01 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8000989
>> 
>> 8000989: smaller code changes to make future JSR 292 backports easier
>> Reviewed-by:
>> 
>> In 8 we added two new constructors to InternalError which we use in
>> 292.  Factor InternalError generation to a method to make future
>> backports to 7u easier.
>> 
>> src/share/classes/java/lang/invoke/BoundMethodHandle.java
>> src/share/classes/java/lang/invoke/CallSite.java
>> src/share/classes/java/lang/invoke/DirectMethodHandle.java
>> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> src/share/classes/java/lang/invoke/Invokers.java
>> src/share/classes/java/lang/invoke/LambdaForm.java
>> src/share/classes/java/lang/invoke/MemberName.java
>> src/share/classes/java/lang/invoke/MethodHandle.java
>> src/share/classes/java/lang/invoke/MethodHandleImpl.java
>> src/share/classes/java/lang/invoke/MethodHandleStatics.java
>> src/share/classes/sun/invoke/util/ValueConversions.java
>> test/java/lang/invoke/BigArityTest.java
>> test/java/lang/invoke/PrivateInvokeTest.java
>> 

From christian.thalinger at oracle.com  Wed Oct 17 08:45:00 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 08:45:00 -0700
Subject: RFR (S): 8000999: backport of JSR 292 to 7u
In-Reply-To: <507E2D0E.8080100@oracle.com>
References: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>
	<507E2D0E.8080100@oracle.com>
Message-ID: <DF6B2CC6-04E6-41A1-925A-EB7134D17129@oracle.com>


On Oct 16, 2012, at 8:59 PM, David Holmes <david.holmes at oracle.com> wrote:

> Hi Christian,
> 
> Is this just a preliminary review request, as actual backport requests have to go to the jdk7u-dev mailing list for approval.

Kind of.  I will pass on the reviewed changes to John Coomes to be integrated in a 7u repository to do PIT.  But I guess I have to send a backport request to jdk7u-dev as well.

> 
> And are these all just bug fixes, or are there any API/spec changes involved?

No API changes.  Just bug fixes (which replaced the whole implementation behind the API).  The HotSpot changes are already in HS24.

-- Chris

> 
> David
> 
> On 17/10/2012 5:54 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8000999
>> 
>> 8000999: backport of JSR 292 to 7u
>> Reviewed-by:
>> 
>> This is an umbrella bug for these changes (which are backported in one
>> changeset):
>> 
>> 6983728: JSR 292 remove argument count limitations
>> 7128512: Javadoc typo in java.lang.invoke.MethodHandle
>> 7117167: Misc warnings in java.lang.invoke and sun.invoke.*
>> 7129034: VM crash with a field setter method with a filterArguments
>> 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited
>> 7127687: MethodType leaks memory due to interning
>> 7023639: JSR 292 method handle invocation needs a fast path for compiled code
>> 7188911: nightly failures after JSR 292 lazy method handle update (round 2)
>> 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize
>> 7191102: nightly failures after JSR 292 lazy method handle update (round 3)
>> 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa
>> 7194662: JSR 292: PermuteArgsTest times out in nightly test runs
>> 
>> The backport is just copying over the files from JDK 8.  That's why the webrev is so big and pretty useless.  The real changes between 8 and 7 are these:
>> 
>> diff -Nur jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java
>> --- jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java    2012-10-15 12:21:52.806052959 -0700
>> +++ jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java   2012-10-16 10:48:29.728257304 -0700
>> @@ -94,10 +94,14 @@
>> 
>>      // handy shared exception makers (they simplify the common case code)
>>      /*non-public*/ static InternalError newInternalError(String message, Throwable cause) {
>> -        return new InternalError(message, cause);
>> +        InternalError e = new InternalError(message);
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>      /*non-public*/ static InternalError newInternalError(Throwable cause) {
>> -        return new InternalError(cause);
>> +        InternalError e = new InternalError();
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>      /*non-public*/ static RuntimeException newIllegalStateException(String message) {
>>          return new IllegalStateException(message);
>> diff -Nur jdk8/src/share/classes/sun/invoke/util/ValueConversions.java jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java
>> --- jdk8/src/share/classes/sun/invoke/util/ValueConversions.java        2012-10-16 10:49:36.081911283 -0700
>> +++ jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java       2012-10-16 10:48:19.626424849 -0700
>> @@ -1211,9 +1211,13 @@
>> 
>>      // handy shared exception makers (they simplify the common case code)
>>      private static InternalError newInternalError(String message, Throwable cause) {
>> -        return new InternalError(message, cause);
>> +        InternalError e = new InternalError(message);
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>      private static InternalError newInternalError(Throwable cause) {
>> -        return new InternalError(cause);
>> +        InternalError e = new InternalError();
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>  }
>> diff --git a/src/share/classes/sun/misc/Unsafe.java b/src/share/classes/sun/misc/Unsafe.java
>> --- a/src/share/classes/sun/misc/Unsafe.java
>> +++ b/src/share/classes/sun/misc/Unsafe.java
>> @@ -678,6 +678,14 @@
>>      public native Object staticFieldBase(Field f);
>> 
>>      /**
>> +     * Detect if the given class may need to be initialized. This is often
>> +     * needed in conjunction with obtaining the static field base of a
>> +     * class.
>> +     * @return false only if a call to {@code ensureClassInitialized} would have no effect
>> +     */
>> +    public native boolean shouldBeInitialized(Class c);
>> +
>> +    /**
>>       * Ensure the given class has been initialized. This is often
>>       * needed in conjunction with obtaining the static field base of a
>>       * class.
>> 

From nils.loodin at oracle.com  Wed Oct 17 08:51:33 2012
From: nils.loodin at oracle.com (Nils Loodin)
Date: Wed, 17 Oct 2012 17:51:33 +0200
Subject: RFR: 8000617: It should be possible to allocate memory without
	the VM dying.
In-Reply-To: <507E9900.1060309@oracle.com>
References: <47D43D24-563F-4363-A264-3C0EF31ABFE9@oracle.com>	<5075DD16.8070602@oracle.com>	<CAHjP37GF8X6nh_NLQfoB94798_e47iofjrTV=K36QOXeFrG4Wg@mail.gmail.com>	<5075E05C.90608@oracle.com>	<CAHjP37F9LdwkL+azn=FN_CKWVfMdKs95Pqg4LZpShAQPzz0sew@mail.gmail.com>	<FBC60867-C9CC-4249-B197-352FAE79130E@oracle.com>	<50760770.4030403@oracle.com>
	<5076ABCF.5020005@oracle.com>	<5076C1C2.30408@oracle.com>
	<50779AAD.30108@oracle.com>	<5077A0CD.2030503@oracle.com>
	<507817AF.1040900@oracle.com>	<1AB9F52B-0272-484D-BFB9-4BF02ED0A1B3@oracle.com>	<4D327F37-E32A-4175-A5C1-09949B0F2AE4@oracle.com>	<5078313B.60404@oracle.com>	<068A58CF-07C1-42F5-B0BD-F04FA4CD39EB@oracle.com>	<507B4658.5090401@oracle.com>	<B0DDF1D0-D771-4782-81EE-8EA278625AF2@oracle.com>
	<507BB1EA.4040605@oracle.com> <507BF639.30807@oracle.com>
	<507BFB12.2040401@oracle.com> <507D5C38.8050409@oracle.com>
	<507E1574.3090507@oracle.com> <507E7178.2090905@oracle.com>
	<507E9900.1060309@oracle.com>
Message-ID: <507ED405.8070206@oracle.com>

A summary of what has happened so far, since I believe the major points 
have been discussed.

John Rose was worried of the added usages of std::, but actually 
removing all of those existing (if appropriate!) would be a separate, 
bigger, change. This is only fixing an outage in a way that' coherent 
with what's already here.

Furthermore, David Holmes has worried about

1. Replacing os::malloc with AllocateHeap, to which me and Coleen has 
argued this intially is a symptom of above mentioned outage, and it will 
add to a better tracing of allocations.

2. That there's an Enum instead of a const bool, to which many have 
argued that this increases type safety, and disallows people 
accidentally sending the wrong boolean.

3. That the name AllocFailStrategy is too long. To which I've rather 
un-eloquently responded 'no it's not, nya nya'.
I think it's the best and most descriptive one I've seen anyway.

David has said that the change webrev.03 does not explicitly go against 
his vision of 'path of least resistance', which I take to mean that it's 
pretty much ok to him anyway.

Coleen and Keith has said that webrev.03 is ok, minus the unfortunate 
mistaken change from nothrow_constant to throw_constant.

Here's a webrev without the error:
http://cr.openjdk.java.net/~nloodin/8000617/webrev.06/

If I missed an important point, please let me know!

Regards,
Nils Loodin

From vladimir.kozlov at oracle.com  Wed Oct 17 11:37:51 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Oct 2012 11:37:51 -0700
Subject: Request for reviews (XS): 8001071: Add simple range check into VM
	implemenation of Unsafe access methods
Message-ID: <507EFAFF.4050406@oracle.com>

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

Range check is not generated for Unsafe accesses. Add simple check in debug 
version of VM.

Thanks,
Vladimir

From krystal.mo at oracle.com  Wed Oct 17 12:09:15 2012
From: krystal.mo at oracle.com (Krystal Mo)
Date: Thu, 18 Oct 2012 03:09:15 +0800
Subject: Request for reviews (XS): 8001071: Add simple range check into
	VM implemenation of Unsafe access methods
In-Reply-To: <507EFAFF.4050406@oracle.com>
References: <507EFAFF.4050406@oracle.com>
Message-ID: <507F025B.9010204@oracle.com>

Looks good to me.

- Kris

On 2012/10/18 2:37, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8001071/webrev
>
> Range check is not generated for Unsafe accesses. Add simple check in 
> debug version of VM.
>
> Thanks,
> Vladimir

From vladimir.kozlov at oracle.com  Wed Oct 17 12:10:57 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Oct 2012 12:10:57 -0700
Subject: Request for reviews (XS): 8001071: Add simple range check into
	VM implemenation of Unsafe access methods
In-Reply-To: <507F025B.9010204@oracle.com>
References: <507EFAFF.4050406@oracle.com> <507F025B.9010204@oracle.com>
Message-ID: <507F02C1.5080606@oracle.com>

Thank you, Kris

Vladimir

Krystal Mo wrote:
> Looks good to me.
> 
> - Kris
> 
> On 2012/10/18 2:37, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8001071/webrev
>>
>> Range check is not generated for Unsafe accesses. Add simple check in 
>> debug version of VM.
>>
>> Thanks,
>> Vladimir

From christian.thalinger at oracle.com  Wed Oct 17 12:20:06 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 12:20:06 -0700
Subject: Request for reviews (XS): 8001071: Add simple range check into VM
	implemenation of Unsafe access methods
In-Reply-To: <507EFAFF.4050406@oracle.com>
References: <507EFAFF.4050406@oracle.com>
Message-ID: <5B299BBE-C0E0-473C-A0EE-E37E57EE881E@oracle.com>

Looks good.  -- Chris

On Oct 17, 2012, at 11:37 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> http://cr.openjdk.java.net/~kvn/8001071/webrev
> 
> Range check is not generated for Unsafe accesses. Add simple check in debug version of VM.
> 
> Thanks,
> Vladimir


From serguei.spitsyn at oracle.com  Wed Oct 17 12:30:31 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 17 Oct 2012 12:30:31 -0700
Subject: Request for reviews (XS): 8001071: Add simple range check into
	VM implemenation of Unsafe access methods
In-Reply-To: <507EFAFF.4050406@oracle.com>
References: <507EFAFF.4050406@oracle.com>
Message-ID: <507F0757.4010209@oracle.com>

Looks good.

Thanks,
Serguei

On 10/17/12 11:37 AM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8001071/webrev
>
> Range check is not generated for Unsafe accesses. Add simple check in 
> debug version of VM.
>
> Thanks,
> Vladimir


From christian.thalinger at oracle.com  Wed Oct 17 14:40:58 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 14:40:58 -0700
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1350399709.2097.4.camel@mercury>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
	<1349988670.1682.16.camel@moonlight>
	<F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>
	<1350399709.2097.4.camel@mercury>
Message-ID: <6FF933F7-CA3D-4E25-9878-38D9F8FF7B03@oracle.com>


On Oct 16, 2012, at 8:01 AM, Roman Kennke <rkennke at redhat.com> wrote:

> Hi Christian,
> 
>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to build
>>>>>> and run with JDK8, and in particular with the latest changes that came
>>>>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>> 
>>>> src/share/vm/asm/codeBuffer.cpp:
>>>> 
>>>> -  if (dest->blob() == NULL) {
>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>> 
>>>> Do we really need this when you have this:
>>> 
>>> The above is needed, because the loop above it that initializes
>>> dest_filled is never executed. However, I will change the test to
>>> dest_filled != NULL :-)
>>> 
>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>> 
>>>> -  memset(to, value, count);
>>>> +  if ( count > 0 ) memset(to, value, count);
>>>> 
>>>> }
>>> 
>>> Turns out that this is 1. not related to the other change above and 2.
>>> not needed. I'll remove it.
>>> 
>>>> src/share/vm/interpreter/interpreter.cpp:
>>>> 
>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
>>>> 
>>>> Why did you need that change?
>>> 
>>> Apparently, before the whole table was initialized, and the methodhandle
>>> related entries left as abstract. Now the methodhandle entries are
>>> simply left to NULL. I suppose we could change the assert to 
>>> 
>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
>>> 
>>> Alternatively, we could fix the code that puts the other entries to also
>>> set the methodhandle entries to AME and go back to the original assert.
>>> What do you think?
>> 
>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
>> 
>>  // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
>>  for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
>>    Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
>>    Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
>>  }                                                                                                                                                              
>> 
>> You need similar code in Zero.
> 
> Alright, I extracted this piece of code into a separate protected method
> void AbstractInterpreterGenerator::initializeMethodHandleEntries() and
> call it both from templateInterpreter and cppInterpreter to initialize
> the method handle entries to AME.
> 
> This new webrev also reverts this:
> 
>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>> 
>>>> -  memset(to, value, count);
>>>> +  if ( count > 0 ) memset(to, value, count);
>>>> 
>>>> }
>> 
> 
> .. and changes the 0x0 to NULL here:
> 
> 
>>> src/share/vm/asm/codeBuffer.cpp:
>>>> 
>>>> -  if (dest->blob() == NULL) {
>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>> 
>> 
> 
> I tried JRuby a little more and verified that it's actually using +indy,
> and it works all well.
> 
> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.01/

It seems this webrev contains the old changes.

-- Chris

> 
> Is this ok to commit now?
> 
> Roman
> 
> 


From rkennke at redhat.com  Wed Oct 17 15:05:46 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 18 Oct 2012 00:05:46 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <6FF933F7-CA3D-4E25-9878-38D9F8FF7B03@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
	<1349988670.1682.16.camel@moonlight>
	<F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>
	<1350399709.2097.4.camel@mercury>
	<6FF933F7-CA3D-4E25-9878-38D9F8FF7B03@oracle.com>
Message-ID: <1350511546.2097.75.camel@mercury>

Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
> On Oct 16, 2012, at 8:01 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> > Hi Christian,
> > 
> >>>>>> In the recent weeks I worked on the Zero interpreter, to get it to build
> >>>>>> and run with JDK8, and in particular with the latest changes that came
> >>>>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> >>>>>> 
> >>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> >>>> 
> >>>> src/share/vm/asm/codeBuffer.cpp:
> >>>> 
> >>>> -  if (dest->blob() == NULL) {
> >>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
> >>>> 
> >>>> Do we really need this when you have this:
> >>> 
> >>> The above is needed, because the loop above it that initializes
> >>> dest_filled is never executed. However, I will change the test to
> >>> dest_filled != NULL :-)
> >>> 
> >>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
> >>>> 
> >>>> -  memset(to, value, count);
> >>>> +  if ( count > 0 ) memset(to, value, count);
> >>>> 
> >>>> }
> >>> 
> >>> Turns out that this is 1. not related to the other change above and 2.
> >>> not needed. I'll remove it.
> >>> 
> >>>> src/share/vm/interpreter/interpreter.cpp:
> >>>> 
> >>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
> >>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
> >>>> 
> >>>> Why did you need that change?
> >>> 
> >>> Apparently, before the whole table was initialized, and the methodhandle
> >>> related entries left as abstract. Now the methodhandle entries are
> >>> simply left to NULL. I suppose we could change the assert to 
> >>> 
> >>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
> >>> 
> >>> Alternatively, we could fix the code that puts the other entries to also
> >>> set the methodhandle entries to AME and go back to the original assert.
> >>> What do you think?
> >> 
> >> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
> >> 
> >>  // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
> >>  for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
> >>    Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
> >>    Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
> >>  }                                                                                                                                                              
> >> 
> >> You need similar code in Zero.
> > 
> > Alright, I extracted this piece of code into a separate protected method
> > void AbstractInterpreterGenerator::initializeMethodHandleEntries() and
> > call it both from templateInterpreter and cppInterpreter to initialize
> > the method handle entries to AME.
> > 
> > This new webrev also reverts this:
> > 
> >>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
> >>>> 
> >>>> -  memset(to, value, count);
> >>>> +  if ( count > 0 ) memset(to, value, count);
> >>>> 
> >>>> }
> >> 
> > 
> > .. and changes the 0x0 to NULL here:
> > 
> > 
> >>> src/share/vm/asm/codeBuffer.cpp:
> >>>> 
> >>>> -  if (dest->blob() == NULL) {
> >>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
> >>>> 
> >> 
> > 
> > I tried JRuby a little more and verified that it's actually using +indy,
> > and it works all well.
> > 
> > http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.01/
> 
> It seems this webrev contains the old changes.

Arg! I did the changes in my hotspot-comp tree then made the webrev in
my hotspot-main :-) Here's the correct one:

http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.02/

Cheers,
Roman



From christian.thalinger at oracle.com  Wed Oct 17 15:34:17 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 15:34:17 -0700
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <1350511546.2097.75.camel@mercury>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
	<1349988670.1682.16.camel@moonlight>
	<F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>
	<1350399709.2097.4.camel@mercury>
	<6FF933F7-CA3D-4E25-9878-38D9F8FF7B03@oracle.com>
	<1350511546.2097.75.camel@mercury>
Message-ID: <CF4C30C2-60C9-4AAE-BD20-183EC074D1D4@oracle.com>


On Oct 17, 2012, at 3:05 PM, Roman Kennke <rkennke at redhat.com> wrote:

> Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
>> On Oct 16, 2012, at 8:01 AM, Roman Kennke <rkennke at redhat.com> wrote:
>> 
>>> Hi Christian,
>>> 
>>>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to build
>>>>>>>> and run with JDK8, and in particular with the latest changes that came
>>>>>>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>>>> 
>>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>> 
>>>>>> -  if (dest->blob() == NULL) {
>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>> 
>>>>>> Do we really need this when you have this:
>>>>> 
>>>>> The above is needed, because the loop above it that initializes
>>>>> dest_filled is never executed. However, I will change the test to
>>>>> dest_filled != NULL :-)
>>>>> 
>>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>> 
>>>>>> -  memset(to, value, count);
>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>> 
>>>>>> }
>>>>> 
>>>>> Turns out that this is 1. not related to the other change above and 2.
>>>>> not needed. I'll remove it.
>>>>> 
>>>>>> src/share/vm/interpreter/interpreter.cpp:
>>>>>> 
>>>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
>>>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
>>>>>> 
>>>>>> Why did you need that change?
>>>>> 
>>>>> Apparently, before the whole table was initialized, and the methodhandle
>>>>> related entries left as abstract. Now the methodhandle entries are
>>>>> simply left to NULL. I suppose we could change the assert to 
>>>>> 
>>>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
>>>>> 
>>>>> Alternatively, we could fix the code that puts the other entries to also
>>>>> set the methodhandle entries to AME and go back to the original assert.
>>>>> What do you think?
>>>> 
>>>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
>>>> 
>>>> // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
>>>> for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
>>>>   Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
>>>>   Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
>>>> }                                                                                                                                                              
>>>> 
>>>> You need similar code in Zero.
>>> 
>>> Alright, I extracted this piece of code into a separate protected method
>>> void AbstractInterpreterGenerator::initializeMethodHandleEntries() and
>>> call it both from templateInterpreter and cppInterpreter to initialize
>>> the method handle entries to AME.
>>> 
>>> This new webrev also reverts this:
>>> 
>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>> 
>>>>>> -  memset(to, value, count);
>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>> 
>>>>>> }
>>>> 
>>> 
>>> .. and changes the 0x0 to NULL here:
>>> 
>>> 
>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>> 
>>>>>> -  if (dest->blob() == NULL) {
>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>> 
>>>> 
>>> 
>>> I tried JRuby a little more and verified that it's actually using +indy,
>>> and it works all well.
>>> 
>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.01/
>> 
>> It seems this webrev contains the old changes.
> 
> Arg! I did the changes in my hotspot-comp tree then made the webrev in
> my hotspot-main :-) Here's the correct one:
> 
> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.02/

That looks better.  The only thing is we don't use camel-case for methods:

+  void initializeMethodHandleEntries();

Could you change it to:

+  void initialize_method_handle_entries();

I would do it myself but I cannot verify that I didn't break Zero.  I really should set up a build environment for Zero...

-- Chris

> 
> Cheers,
> Roman
> 
> 


From rkennke at redhat.com  Wed Oct 17 16:09:13 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 18 Oct 2012 01:09:13 +0200
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <CF4C30C2-60C9-4AAE-BD20-183EC074D1D4@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
	<1349988670.1682.16.camel@moonlight>
	<F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>
	<1350399709.2097.4.camel@mercury>
	<6FF933F7-CA3D-4E25-9878-38D9F8FF7B03@oracle.com>
	<1350511546.2097.75.camel@mercury>
	<CF4C30C2-60C9-4AAE-BD20-183EC074D1D4@oracle.com>
Message-ID: <1350515353.2097.80.camel@mercury>

Am Mittwoch, den 17.10.2012, 15:34 -0700 schrieb Christian Thalinger:
> On Oct 17, 2012, at 3:05 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> > Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
> >> On Oct 16, 2012, at 8:01 AM, Roman Kennke <rkennke at redhat.com> wrote:
> >> 
> >>> Hi Christian,
> >>> 
> >>>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to build
> >>>>>>>> and run with JDK8, and in particular with the latest changes that came
> >>>>>>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> >>>>>>>> 
> >>>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> >>>>>> 
> >>>>>> src/share/vm/asm/codeBuffer.cpp:
> >>>>>> 
> >>>>>> -  if (dest->blob() == NULL) {
> >>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
> >>>>>> 
> >>>>>> Do we really need this when you have this:
> >>>>> 
> >>>>> The above is needed, because the loop above it that initializes
> >>>>> dest_filled is never executed. However, I will change the test to
> >>>>> dest_filled != NULL :-)
> >>>>> 
> >>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
> >>>>>> 
> >>>>>> -  memset(to, value, count);
> >>>>>> +  if ( count > 0 ) memset(to, value, count);
> >>>>>> 
> >>>>>> }
> >>>>> 
> >>>>> Turns out that this is 1. not related to the other change above and 2.
> >>>>> not needed. I'll remove it.
> >>>>> 
> >>>>>> src/share/vm/interpreter/interpreter.cpp:
> >>>>>> 
> >>>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
> >>>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
> >>>>>> 
> >>>>>> Why did you need that change?
> >>>>> 
> >>>>> Apparently, before the whole table was initialized, and the methodhandle
> >>>>> related entries left as abstract. Now the methodhandle entries are
> >>>>> simply left to NULL. I suppose we could change the assert to 
> >>>>> 
> >>>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
> >>>>> 
> >>>>> Alternatively, we could fix the code that puts the other entries to also
> >>>>> set the methodhandle entries to AME and go back to the original assert.
> >>>>> What do you think?
> >>>> 
> >>>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
> >>>> 
> >>>> // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
> >>>> for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
> >>>>   Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
> >>>>   Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
> >>>> }                                                                                                                                                              
> >>>> 
> >>>> You need similar code in Zero.
> >>> 
> >>> Alright, I extracted this piece of code into a separate protected method
> >>> void AbstractInterpreterGenerator::initializeMethodHandleEntries() and
> >>> call it both from templateInterpreter and cppInterpreter to initialize
> >>> the method handle entries to AME.
> >>> 
> >>> This new webrev also reverts this:
> >>> 
> >>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
> >>>>>> 
> >>>>>> -  memset(to, value, count);
> >>>>>> +  if ( count > 0 ) memset(to, value, count);
> >>>>>> 
> >>>>>> }
> >>>> 
> >>> 
> >>> .. and changes the 0x0 to NULL here:
> >>> 
> >>> 
> >>>>> src/share/vm/asm/codeBuffer.cpp:
> >>>>>> 
> >>>>>> -  if (dest->blob() == NULL) {
> >>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
> >>>>>> 
> >>>> 
> >>> 
> >>> I tried JRuby a little more and verified that it's actually using +indy,
> >>> and it works all well.
> >>> 
> >>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.01/
> >> 
> >> It seems this webrev contains the old changes.
> > 
> > Arg! I did the changes in my hotspot-comp tree then made the webrev in
> > my hotspot-main :-) Here's the correct one:
> > 
> > http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.02/
> 
> That looks better.  The only thing is we don't use camel-case for methods:
> 
> +  void initializeMethodHandleEntries();
> 
> Could you change it to:
> 
> +  void initialize_method_handle_entries();
> 
> I would do it myself but I cannot verify that I didn't break Zero.  I really should set up a build environment for Zero...

Here it comes:

http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.03/

I built both Zero and normal debug_build successfully.

Cheers,
Roman



From christian.thalinger at oracle.com  Wed Oct 17 17:13:41 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 17:13:41 -0700
Subject: RFR: Make Zero build and run with JDK8
In-Reply-To: <CF4C30C2-60C9-4AAE-BD20-183EC074D1D4@oracle.com>
References: <1349967309.1682.12.camel@moonlight>
	<3308D355-F1A9-459C-830F-42D3056F8CE2@oracle.com>
	<E8F4DA0C-5E8C-45F3-9AAE-84A19C3EAB4D@oracle.com>
	<1349988670.1682.16.camel@moonlight>
	<F3F0E892-BD40-439C-A71E-4774E40FB864@oracle.com>
	<1350399709.2097.4.camel@mercury>
	<6FF933F7-CA3D-4E25-9878-38D9F8FF7B03@oracle.com>
	<1350511546.2097.75.camel@mercury>
	<CF4C30C2-60C9-4AAE-BD20-183EC074D1D4@oracle.com>
Message-ID: <A25F9323-BFE4-4F2F-8F22-C3E2D0CCF424@oracle.com>


On Oct 17, 2012, at 3:34 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Oct 17, 2012, at 3:05 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
>> Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
>>> On Oct 16, 2012, at 8:01 AM, Roman Kennke <rkennke at redhat.com> wrote:
>>> 
>>>> Hi Christian,
>>>> 
>>>>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to build
>>>>>>>>> and run with JDK8, and in particular with the latest changes that came
>>>>>>>>> from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>>>>> 
>>>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>>> 
>>>>>>> -  if (dest->blob() == NULL) {
>>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>>> 
>>>>>>> Do we really need this when you have this:
>>>>>> 
>>>>>> The above is needed, because the loop above it that initializes
>>>>>> dest_filled is never executed. However, I will change the test to
>>>>>> dest_filled != NULL :-)
>>>>>> 
>>>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>>> 
>>>>>>> -  memset(to, value, count);
>>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>>> 
>>>>>>> }
>>>>>> 
>>>>>> Turns out that this is 1. not related to the other change above and 2.
>>>>>> not needed. I'll remove it.
>>>>>> 
>>>>>>> src/share/vm/interpreter/interpreter.cpp:
>>>>>>> 
>>>>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
>>>>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
>>>>>>> 
>>>>>>> Why did you need that change?
>>>>>> 
>>>>>> Apparently, before the whole table was initialized, and the methodhandle
>>>>>> related entries left as abstract. Now the methodhandle entries are
>>>>>> simply left to NULL. I suppose we could change the assert to 
>>>>>> 
>>>>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
>>>>>> 
>>>>>> Alternatively, we could fix the code that puts the other entries to also
>>>>>> set the methodhandle entries to AME and go back to the original assert.
>>>>>> What do you think?
>>>>> 
>>>>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
>>>>> 
>>>>> // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
>>>>> for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
>>>>>  Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
>>>>>  Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
>>>>> }                                                                                                                                                              
>>>>> 
>>>>> You need similar code in Zero.
>>>> 
>>>> Alright, I extracted this piece of code into a separate protected method
>>>> void AbstractInterpreterGenerator::initializeMethodHandleEntries() and
>>>> call it both from templateInterpreter and cppInterpreter to initialize
>>>> the method handle entries to AME.
>>>> 
>>>> This new webrev also reverts this:
>>>> 
>>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>>> 
>>>>>>> -  memset(to, value, count);
>>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>>> 
>>>>>>> }
>>>>> 
>>>> 
>>>> .. and changes the 0x0 to NULL here:
>>>> 
>>>> 
>>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>>> 
>>>>>>> -  if (dest->blob() == NULL) {
>>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>>> 
>>>>> 
>>>> 
>>>> I tried JRuby a little more and verified that it's actually using +indy,
>>>> and it works all well.
>>>> 
>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.01/
>>> 
>>> It seems this webrev contains the old changes.
>> 
>> Arg! I did the changes in my hotspot-comp tree then made the webrev in
>> my hotspot-main :-) Here's the correct one:
>> 
>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.02/
> 
> That looks better.  The only thing is we don't use camel-case for methods:
> 
> +  void initializeMethodHandleEntries();
> 
> Could you change it to:
> 
> +  void initialize_method_handle_entries();
> 
> I would do it myself but I cannot verify that I didn't break Zero.  I really should set up a build environment for Zero...

I'm in the game:

$ java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b60)
OpenJDK 64-Bit Zero VM (build 25.0-b06-internal-jvmg, interpreted mode)

-- Chris

> 
> -- Chris
> 
>> 
>> Cheers,
>> Roman
>> 
>> 
> 


From jon.masamitsu at oracle.com  Wed Oct 17 17:29:54 2012
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Thu, 18 Oct 2012 00:29:54 +0000
Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets
Message-ID: <20121018003007.2014647403@hg.openjdk.java.net>

Changeset: 8a5ea0a9ccc4
Author:    johnc
Date:      2012-10-06 01:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8a5ea0a9ccc4

7127708: G1: change task num types from int to uint in concurrent mark
Summary: Change the type of various task num fields, parameters etc to unsigned and rename them to be more consistent with the other collectors. Code changes were also reviewed by Vitaly Davidovich.
Reviewed-by: johnc
Contributed-by: Kaushik Srenevasan <kaushik at twitter.com>

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp

Changeset: 04155d9c8c76
Author:    johnc
Date:      2012-10-08 09:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/04155d9c8c76

8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file
Summary: Missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on().
Reviewed-by: azeemj, jmasa
Contributed-by: Mikael Gerdin <mikael.gerdin at oracle.com>

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

Changeset: dd2b66d09ccd
Author:    stefank
Date:      2012-10-09 22:12 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dd2b66d09ccd

8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn
Summary: Treat the oops in invoke_method_table() as strong roots when ClassUnloading is enabled.
Reviewed-by: kamg, coleenp

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

Changeset: 4202510ee0fe
Author:    johnc
Date:      2012-10-15 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4202510ee0fe

8000831: Heap verification output incorrect/incomplete
Summary: Restore non-silent output of heap verification.
Reviewed-by: ysr, brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/utilities/debug.cpp

Changeset: 633ba56cb013
Author:    jmasa
Date:      2012-10-17 13:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/633ba56cb013

Merge

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/memory/universe.hpp


From rickard.backman at oracle.com  Thu Oct 18 03:27:45 2012
From: rickard.backman at oracle.com (rickard.backman at oracle.com)
Date: Thu, 18 Oct 2012 10:27:45 +0000
Subject: hg: hsx/hsx24/hotspot: 7093328: JVMTI: jvmtiPrimitiveFieldCallback
	always report 0's for static primitives
Message-ID: <20121018102756.5C3C947412@hg.openjdk.java.net>

Changeset: 16f3116e792d
Author:    rbackman
Date:      2012-10-18 08:04 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/16f3116e792d

7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives
Reviewed-by: dholmes, dcubed

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


From coleen.phillimore at oracle.com  Thu Oct 18 11:44:48 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 18 Oct 2012 18:44:48 +0000
Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets
Message-ID: <20121018184504.7C1094741B@hg.openjdk.java.net>

Changeset: bdb5f8c9978b
Author:    coleenp
Date:      2012-10-10 17:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bdb5f8c9978b

7199068: NPG: SharedSkipVerify is meaningless
Summary: Remove the SharedSkipVerify flag
Reviewed-by: kamg, sspitsyn, coleenp
Contributed-by: harold.seigel at oracle.com

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp

Changeset: 48a75d2640a5
Author:    kamg
Date:      2012-10-11 14:27 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/48a75d2640a5

7054345: Support version 52.0 class file in HotSpot
Summary: Accept classfiles with major version 52
Reviewed-by: coleenp, acorn

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

Changeset: e0ea0e94c23c
Author:    kevinw
Date:      2012-10-15 16:48 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0ea0e94c23c

7195151: Multiplatform tescase for 6929067
Reviewed-by: kamg, kvn

! test/runtime/6929067/Test6929067.sh

Changeset: e52361627b65
Author:    coleenp
Date:      2012-10-15 22:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e52361627b65

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 045cb62046a7
Author:    rbackman
Date:      2012-08-28 15:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/045cb62046a7

7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives
Reviewed-by: dholmes, dcubed

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

Changeset: 7b5885dadbdc
Author:    nloodin
Date:      2012-10-17 17:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7b5885dadbdc

8000617: It should be possible to allocate memory without the VM dying.
Reviewed-by: coleenp, kamg

! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/resourceArea.cpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: e8c79c2ba3f3
Author:    coleenp
Date:      2012-10-18 12:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e8c79c2ba3f3

Merge



From zhengyu.gu at oracle.com  Thu Oct 18 11:54:16 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Thu, 18 Oct 2012 14:54:16 -0400
Subject: Code review request: 7199092  NMT: NMT needs to deal overlapped
	virtual memory ranges
In-Reply-To: <50660A67.1010901@oracle.com>
References: <50660A67.1010901@oracle.com>
Message-ID: <50805058.6050109@oracle.com>

The new webrev reflects some suggestions from previous code review, 
along with:

1. Caught more cases that virtual memory operations do not go through os 
api, which cause mis-matched records that confuse NMT.
2. Fixed a bug that JavaThread releases its per-thread recorder too 
later, so that the record could be misplaced in wrong generation.
3. Cleanup. Removed some dead code and unnecessary assertions
4. Fixed racing conditions that could mis-count arena sizes. When 
ResourceMark or HandleMark resets, it should reset arena size first, 
before release memory chunks.
5. Fixed missing call to record native stack on AttachListener thread.
6.  Removed unused Arena constructor.

Webrev: http://cr.openjdk.java.net/~zgu/7199092/webrev.01/

Thanks,

-Zhengyu


On 9/28/2012 4:36 PM, Zhengyu Gu wrote:
> With PermGen removal integration, virtual memory usage patterns have 
> changed vs. earlier. NMT can not longer just track reserved memory 
> regions, and assume commits and uncommits are performed from the tail 
> end.
>
> NMT now tracks committed memory regions, alone with reserved memory 
> regions, a virtual memory map is maintained by NMT, and it is reported 
> with detail tracking data.
>
> The changes also include some cleanup and enhanced assertion, etc.
>
> CR: http://bugs.sun.com/view_bug.do?bug_id=7199092
> Webrev:  http://cr.openjdk.java.net/~zgu/7199092/webrev.00/
>
>
> An example of virtual memory map:
>
> Virtual memory map:
>
> [0x8f17e000 - 0x8f364000] reserved 1944KB for Thread Stack
>         from [Thread::record_stack_base_and_size()+0x120]
>     [0x8f17e000 - 0x8f364000] committed 1944KB from 
> [Thread::record_stack_base_and_size()+0x120]
>
> [0x8f389000 - 0x8f680000] reserved 3036KB for Thread Stack
>         from [Thread::record_stack_base_and_size()+0x120]
>     [0x8f389000 - 0x8f680000] committed 3036KB from 
> [Thread::record_stack_base_and_size()+0x120]
>
> [0x8f7dd000 - 0x8f900000] reserved 1164KB for Thread Stack
>         from [Thread::record_stack_base_and_size()+0x120]
>     [0x8f7dd000 - 0x8f900000] committed 1164KB from 
> [Thread::record_stack_base_and_size()+0x120]
>
> [0x8fa20000 - 0x8faa1000] reserved 516KB for Thread Stack
>         from [Thread::record_stack_base_and_size()+0x120]
>     [0x8fa20000 - 0x8faa1000] committed 516KB from 
> [Thread::record_stack_base_and_size()+0x120]
>
> [0x8fd30000 - 0x914b8000] reserved 24096KB for GC
>         from [ReservedSpace::initialize(unsigned int, unsigned int, 
> bool, char*, unsigned int, bool)+0x555]
>     [0x8fd30000 - 0x914b8000] committed 24096KB from 
> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>
> [0x914b8000 - 0x916bc000] reserved 2064KB for Thread Stack
>         from [Thread::record_stack_base_and_size()+0x120]
>     [0x914b8000 - 0x916bc000] committed 2064KB from 
> [Thread::record_stack_base_and_size()+0x120]
>
> [0x916bc000 - 0x91860000] reserved 1680KB for GC
>         from [ReservedSpace::initialize(unsigned int, unsigned int, 
> bool, char*, unsigned int, bool)+0x555]
>     [0x916bc000 - 0x916c7000] committed 44KB from 
> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>     [0x91764000 - 0x9176f000] committed 44KB from 
> [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>     [0x9180b000 - 0x91811000] committed 24KB from 
> [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>     [0x9185f000 - 0x91860000] committed 4KB from 
> [CardTableModRefBS::CardTableModRefBS(MemRegion, int)+0x2a0]
>
> [0x91860000 - 0xb1060000] reserved 516096KB for Java Heap
>         from [ReservedSpace::initialize(unsigned int, unsigned int, 
> bool, char*, unsigned int, bool)+0x190]
>     [0x91860000 - 0x92d50000] committed 21440KB from 
> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>     [0xa6710000 - 0xa7180000] committed 10688KB from 
> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>     [0xb0e60000 - 0xb0ea9000] committed 292KB from 
> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>
> [0xb1069000 - 0xb71e9000] reserved 99840KB for Code
>         from [ReservedSpace::initialize(unsigned int, unsigned int, 
> bool, char*, unsigned int, bool)+0x555]
>     [0xb1069000 - 0xb1072000] committed 36KB from 
> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>     [0xb11e9000 - 0xb1429000] committed 2304KB from 
> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>
> [0xb71e9000 - 0xb77e9000] reserved 6144KB for Class
>         from [ReservedSpace::initialize(unsigned int, unsigned int, 
> bool, char*, unsigned int, bool)+0x555]
>     [0xb71e9000 - 0xb750a000] committed 3204KB from 
> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>
> [0xb77e9000 - 0xb783a000] reserved 324KB for Thread Stack
>         from [Thread::record_stack_base_and_size()+0x120]
>     [0xb77e9000 - 0xb783a000] committed 324KB from 
> [Thread::record_stack_base_and_size()+0x120]
>
> Tests performed:
> - JPRT tests
>
> - Linux 32 bit:
>     vm.quick.testlist
>     nsk.stress
>     runtime.ParallelClassLoading
>     nsk.quick-jdi.testlist
>     nsk.quick-jvmti.testlist
>
> - Solaris x64
>     vm.quick.testlist
>     runtime.ParallelClassLoading
>     nsk.stress.jck60
>
> - Solaris sparcv9
>     vm.quick.testlist
>     runtime.ParallelClassLoading
>     nsk.stress.jck60
>
>
> Thanks,
>
> -Zhengyu

From david.holmes at oracle.com  Thu Oct 18 16:48:16 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Oct 2012 09:48:16 +1000
Subject: Code review request: 7199092  NMT: NMT needs to deal overlapped
	virtual memory ranges
In-Reply-To: <50805058.6050109@oracle.com>
References: <50660A67.1010901@oracle.com> <50805058.6050109@oracle.com>
Message-ID: <50809540.8090003@oracle.com>

Hi Zhengyu,

I can't review the details of this (sorry) but one minor comment:

thread.cpp

1518   // Info NMT that this JavaThread is exiting, its memory
1519   // recorder should be collected
1520   assert(!is_safepoint_visible(), "wrong state");
1521   assert(get_recorder() == NULL, "Already collected");

The comment is no longer appropriate now that you aren't calling 
thread_exiting here.

David
-----

On 19/10/2012 4:54 AM, Zhengyu Gu wrote:
> The new webrev reflects some suggestions from previous code review,
> along with:
>
> 1. Caught more cases that virtual memory operations do not go through os
> api, which cause mis-matched records that confuse NMT.
> 2. Fixed a bug that JavaThread releases its per-thread recorder too
> later, so that the record could be misplaced in wrong generation.
> 3. Cleanup. Removed some dead code and unnecessary assertions
> 4. Fixed racing conditions that could mis-count arena sizes. When
> ResourceMark or HandleMark resets, it should reset arena size first,
> before release memory chunks.
> 5. Fixed missing call to record native stack on AttachListener thread.
> 6. Removed unused Arena constructor.
>
> Webrev: http://cr.openjdk.java.net/~zgu/7199092/webrev.01/
>
> Thanks,
>
> -Zhengyu
>
>
> On 9/28/2012 4:36 PM, Zhengyu Gu wrote:
>> With PermGen removal integration, virtual memory usage patterns have
>> changed vs. earlier. NMT can not longer just track reserved memory
>> regions, and assume commits and uncommits are performed from the tail
>> end.
>>
>> NMT now tracks committed memory regions, alone with reserved memory
>> regions, a virtual memory map is maintained by NMT, and it is reported
>> with detail tracking data.
>>
>> The changes also include some cleanup and enhanced assertion, etc.
>>
>> CR: http://bugs.sun.com/view_bug.do?bug_id=7199092
>> Webrev: http://cr.openjdk.java.net/~zgu/7199092/webrev.00/
>>
>>
>> An example of virtual memory map:
>>
>> Virtual memory map:
>>
>> [0x8f17e000 - 0x8f364000] reserved 1944KB for Thread Stack
>> from [Thread::record_stack_base_and_size()+0x120]
>> [0x8f17e000 - 0x8f364000] committed 1944KB from
>> [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8f389000 - 0x8f680000] reserved 3036KB for Thread Stack
>> from [Thread::record_stack_base_and_size()+0x120]
>> [0x8f389000 - 0x8f680000] committed 3036KB from
>> [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8f7dd000 - 0x8f900000] reserved 1164KB for Thread Stack
>> from [Thread::record_stack_base_and_size()+0x120]
>> [0x8f7dd000 - 0x8f900000] committed 1164KB from
>> [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8fa20000 - 0x8faa1000] reserved 516KB for Thread Stack
>> from [Thread::record_stack_base_and_size()+0x120]
>> [0x8fa20000 - 0x8faa1000] committed 516KB from
>> [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x8fd30000 - 0x914b8000] reserved 24096KB for GC
>> from [ReservedSpace::initialize(unsigned int, unsigned int, bool,
>> char*, unsigned int, bool)+0x555]
>> [0x8fd30000 - 0x914b8000] committed 24096KB from
>> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>
>> [0x914b8000 - 0x916bc000] reserved 2064KB for Thread Stack
>> from [Thread::record_stack_base_and_size()+0x120]
>> [0x914b8000 - 0x916bc000] committed 2064KB from
>> [Thread::record_stack_base_and_size()+0x120]
>>
>> [0x916bc000 - 0x91860000] reserved 1680KB for GC
>> from [ReservedSpace::initialize(unsigned int, unsigned int, bool,
>> char*, unsigned int, bool)+0x555]
>> [0x916bc000 - 0x916c7000] committed 44KB from
>> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>> [0x91764000 - 0x9176f000] committed 44KB from
>> [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>> [0x9180b000 - 0x91811000] committed 24KB from
>> [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>> [0x9185f000 - 0x91860000] committed 4KB from
>> [CardTableModRefBS::CardTableModRefBS(MemRegion, int)+0x2a0]
>>
>> [0x91860000 - 0xb1060000] reserved 516096KB for Java Heap
>> from [ReservedSpace::initialize(unsigned int, unsigned int, bool,
>> char*, unsigned int, bool)+0x190]
>> [0x91860000 - 0x92d50000] committed 21440KB from
>> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>> [0xa6710000 - 0xa7180000] committed 10688KB from
>> [PSVirtualSpace::expand_by(unsigned int)+0x95]
>> [0xb0e60000 - 0xb0ea9000] committed 292KB from
>> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>
>> [0xb1069000 - 0xb71e9000] reserved 99840KB for Code
>> from [ReservedSpace::initialize(unsigned int, unsigned int, bool,
>> char*, unsigned int, bool)+0x555]
>> [0xb1069000 - 0xb1072000] committed 36KB from
>> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>> [0xb11e9000 - 0xb1429000] committed 2304KB from
>> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>
>> [0xb71e9000 - 0xb77e9000] reserved 6144KB for Class
>> from [ReservedSpace::initialize(unsigned int, unsigned int, bool,
>> char*, unsigned int, bool)+0x555]
>> [0xb71e9000 - 0xb750a000] committed 3204KB from
>> [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>
>> [0xb77e9000 - 0xb783a000] reserved 324KB for Thread Stack
>> from [Thread::record_stack_base_and_size()+0x120]
>> [0xb77e9000 - 0xb783a000] committed 324KB from
>> [Thread::record_stack_base_and_size()+0x120]
>>
>> Tests performed:
>> - JPRT tests
>>
>> - Linux 32 bit:
>> vm.quick.testlist
>> nsk.stress
>> runtime.ParallelClassLoading
>> nsk.quick-jdi.testlist
>> nsk.quick-jvmti.testlist
>>
>> - Solaris x64
>> vm.quick.testlist
>> runtime.ParallelClassLoading
>> nsk.stress.jck60
>>
>> - Solaris sparcv9
>> vm.quick.testlist
>> runtime.ParallelClassLoading
>> nsk.stress.jck60
>>
>>
>> Thanks,
>>
>> -Zhengyu

From john.r.rose at oracle.com  Thu Oct 18 17:26:35 2012
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 18 Oct 2012 17:26:35 -0700
Subject: Request for reviews (XS): 8001071: Add simple range check into VM
	implemenation of Unsafe access methods
In-Reply-To: <507EFAFF.4050406@oracle.com>
References: <507EFAFF.4050406@oracle.com>
Message-ID: <64FE7388-9CE2-4862-AE71-1DDE1905771C@oracle.com>

Good.

I suggest a similar err_msg for the check against MAX_OBJECT_SIZE a few lines up.

? John

On Oct 17, 2012, at 11:37 AM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/8001071/webrev
> 
> Range check is not generated for Unsafe accesses. Add simple check in debug version of VM.
> 
> Thanks,
> Vladimir


From vladimir.kozlov at oracle.com  Thu Oct 18 17:29:26 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Oct 2012 17:29:26 -0700
Subject: Request for reviews (XS): 8001071: Add simple range check into
	VM implemenation of Unsafe access methods
In-Reply-To: <64FE7388-9CE2-4862-AE71-1DDE1905771C@oracle.com>
References: <507EFAFF.4050406@oracle.com>
	<64FE7388-9CE2-4862-AE71-1DDE1905771C@oracle.com>
Message-ID: <50809EE6.9080202@oracle.com>

Sorry, John, I pushed it into repo already.

Thanks,
Vladimir

John Rose wrote:
> Good.
> 
> I suggest a similar err_msg for the check against MAX_OBJECT_SIZE a few lines up.
> 
> ? John
> 
> On Oct 17, 2012, at 11:37 AM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/8001071/webrev
>>
>> Range check is not generated for Unsafe accesses. Add simple check in debug version of VM.
>>
>> Thanks,
>> Vladimir
> 

From john.r.rose at oracle.com  Thu Oct 18 17:32:10 2012
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 18 Oct 2012 17:32:10 -0700
Subject: Request for reviews (XS): 8001071: Add simple range check into VM
	implemenation of Unsafe access methods
In-Reply-To: <50809EE6.9080202@oracle.com>
References: <507EFAFF.4050406@oracle.com>
	<64FE7388-9CE2-4862-AE71-1DDE1905771C@oracle.com>
	<50809EE6.9080202@oracle.com>
Message-ID: <EB3BD8B6-DD93-448F-9B3C-FA8222258504@oracle.com>

On Oct 18, 2012, at 5:29 PM, Vladimir Kozlov wrote:

> Sorry, John, I pushed it into repo already.

You're fast!  Thanks anyway.  ? John

From john.coomes at oracle.com  Thu Oct 18 20:32:17 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Oct 2012 03:32:17 +0000
Subject: hg: hsx/hotspot-main: Added tag jdk8-b61 for changeset 20ff117b5090
Message-ID: <20121019033218.5ACEC4742E@hg.openjdk.java.net>

Changeset: 8343ccdd63f1
Author:    katleman
Date:      2012-10-18 11:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/8343ccdd63f1

Added tag jdk8-b61 for changeset 20ff117b5090

! .hgtags


From john.coomes at oracle.com  Thu Oct 18 20:32:22 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Oct 2012 03:32:22 +0000
Subject: hg: hsx/hotspot-main/corba: 4 new changesets
Message-ID: <20121019033229.82DAE4742F@hg.openjdk.java.net>

Changeset: 27d87f0031bf
Author:    alanb
Date:      2012-10-05 15:08 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/27d87f0031bf

7195779: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently, NPE in tie class
Reviewed-by: alanb, coffeys
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java

Changeset: d9c1dab1515b
Author:    lana
Date:      2012-10-08 15:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d9c1dab1515b

Merge


Changeset: 0e08ba7648fb
Author:    lana
Date:      2012-10-11 16:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0e08ba7648fb

Merge


Changeset: 2394155f9f9e
Author:    katleman
Date:      2012-10-18 11:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/2394155f9f9e

Added tag jdk8-b61 for changeset 0e08ba7648fb

! .hgtags


From john.coomes at oracle.com  Thu Oct 18 20:32:33 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Oct 2012 03:32:33 +0000
Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b61 for changeset
	6b1db0b41d2f
Message-ID: <20121019033246.2DB5F47430@hg.openjdk.java.net>

Changeset: 5d0fa0108d02
Author:    katleman
Date:      2012-10-18 11:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/5d0fa0108d02

Added tag jdk8-b61 for changeset 6b1db0b41d2f

! .hgtags


From john.coomes at oracle.com  Thu Oct 18 20:32:50 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Oct 2012 03:32:50 +0000
Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b61 for changeset
	97e5e74e2a34
Message-ID: <20121019033257.6985847431@hg.openjdk.java.net>

Changeset: d265b9b4c0f5
Author:    katleman
Date:      2012-10-18 11:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d265b9b4c0f5

Added tag jdk8-b61 for changeset 97e5e74e2a34

! .hgtags


From john.coomes at oracle.com  Thu Oct 18 20:34:18 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Oct 2012 03:34:18 +0000
Subject: hg: hsx/hotspot-main/jdk: 51 new changesets
Message-ID: <20121019034446.C99B247432@hg.openjdk.java.net>

Changeset: 4d8b411a2bc1
Author:    jgodinez
Date:      2012-09-25 09:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d8b411a2bc1

7158350: [macosx] Strange results of SwingUIText printing
Reviewed-by: bae, prr

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: 5aff878baaf6
Author:    lana
Date:      2012-09-28 11:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5aff878baaf6

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk
- src/macosx/classes/sun/awt/SunToolkitSubclass.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 8dd4cae72975
Author:    ceisserer
Date:      2012-10-01 13:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8dd4cae72975

7188093: closed/sun/java2d/pipe/ScaleQualityTest.java fails
Reviewed-by: prr, flar

! src/solaris/classes/sun/java2d/xr/XRDrawImage.java

Changeset: 89a1094e384f
Author:    bae
Date:      2012-10-05 16:21 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89a1094e384f

8000176: Need automated test for checking scale quality
Reviewed-by: prr, bae
Contributed-by: Vadim Pakhnushev <vadim.pakhnushev at oracle.com>

+ test/sun/java2d/pipe/InterpolationQualityTest.java

Changeset: 2bc7669294cc
Author:    lana
Date:      2012-10-08 15:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2bc7669294cc

Merge


Changeset: 9aa37a39cf39
Author:    zhouyx
Date:      2012-09-20 17:39 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9aa37a39cf39

7194184: JColorChooser swatch cannot accessed from keyboard
Reviewed-by: rupashka, alexsch

! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java
+ test/javax/swing/JColorChooser/Test7194184.java

Changeset: 4f519691520c
Author:    vkarnauk
Date:      2012-09-20 17:55 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4f519691520c

7123767: Wrong tooltip location in Multi-Monitor configurations
Reviewed-by: rupashka

! src/share/classes/javax/swing/ToolTipManager.java
+ test/javax/swing/ToolTipManager/7123767/bug7123767.java

Changeset: adddc599e551
Author:    alexsch
Date:      2012-09-21 13:48 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/adddc599e551

7199180: [macosx] Dead keys handling for input methods
Reviewed-by: kizune, anthony

! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/native/sun/awt/AWTEvent.m
! src/macosx/native/sun/awt/AWTView.m
+ test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java

Changeset: 88048b34405e
Author:    leonidr
Date:      2012-09-24 15:25 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88048b34405e

7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper
Reviewed-by: anthony

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

Changeset: d6cba7bfbb3d
Author:    leonidr
Date:      2012-09-24 18:24 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d6cba7bfbb3d

7179349: [macosx] Java processes on Mac should not use default Apple icon
Reviewed-by: anthony

! make/sun/osxapp/Makefile
+ make/sun/osxapp/ToBin.java
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
+ src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns

Changeset: 39227bb92978
Author:    serb
Date:      2012-09-24 21:33 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39227bb92978

7160627: [macosx] TextArea has wrong initial size
7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms
Reviewed-by: anthony, art

! src/macosx/classes/sun/lwawt/LWCanvasPeer.java
! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWContainerPeer.java
! src/macosx/classes/sun/lwawt/LWLabelPeer.java
! src/macosx/classes/sun/lwawt/LWListPeer.java
! src/macosx/classes/sun/lwawt/LWPanelPeer.java
! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java
! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java
! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java
! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java
! src/macosx/classes/sun/lwawt/LWToolkit.java
+ test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java
+ test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java

Changeset: c8da47a4d441
Author:    alexsch
Date:      2012-09-26 18:59 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c8da47a4d441

7124515: [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items)
Reviewed-by: serb, anthony

+ test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java

Changeset: ad467dee852a
Author:    alexsch
Date:      2012-09-28 14:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad467dee852a

7197619: Using modifiers for the dead key detection on Windows
Reviewed-by: bagiras, leonidr

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Component.h

Changeset: 4b8bb77fdda9
Author:    lana
Date:      2012-09-28 10:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b8bb77fdda9

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 3ac112755bb5
Author:    bagiras
Date:      2012-10-03 21:01 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3ac112755bb5

7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call
Reviewed-by: art, denis

! src/macosx/native/sun/awt/InitIDs.m
! src/share/classes/java/awt/Choice.java
! src/solaris/native/sun/awt/initIDs.c
! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Choice.h
+ test/java/awt/Choice/ItemStateChangeTest/ItemStateChangeTest.java

Changeset: 27ee94051373
Author:    lana
Date:      2012-10-08 15:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27ee94051373

Merge


Changeset: f5229879ea40
Author:    chegar
Date:      2012-09-20 09:36 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f5229879ea40

7193520: Removed references to Linux kernel version 2.2
Summary: Linux kernel version 2.2 isn't supported anymore.
Reviewed-by: chegar, dsamersoff, alanb
Contributed-by: John Zavgren <john.zavgren at oracle.com>

! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/PlainSocketImpl.c
! src/solaris/native/java/net/SocketInputStream.c
! src/solaris/native/java/net/bsd_close.c
! src/solaris/native/java/net/net_util_md.c
! src/solaris/native/java/net/net_util_md.h

Changeset: 3ad5464e7a21
Author:    ksrini
Date:      2012-09-20 13:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3ad5464e7a21

7199614: (pack200) remove unused file
Reviewed-by: alanb

- src/share/test/pack200/pack.conf

Changeset: 3cfb621d5e7e
Author:    alanb
Date:      2012-09-21 15:39 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3cfb621d5e7e

7199551: (bf) CharBuffer.append(CharSequence) throws BufferOverflowException for read-only buffer
Reviewed-by: iris, dxu, chegar

! src/share/classes/java/nio/X-Buffer.java.template
! test/java/nio/Buffer/Basic-X.java.template
! test/java/nio/Buffer/Basic.java
! test/java/nio/Buffer/BasicByte.java
! test/java/nio/Buffer/BasicChar.java
! test/java/nio/Buffer/BasicDouble.java
! test/java/nio/Buffer/BasicFloat.java
! test/java/nio/Buffer/BasicInt.java
! test/java/nio/Buffer/BasicLong.java
! test/java/nio/Buffer/BasicShort.java

Changeset: f0aa997ad78b
Author:    valeriep
Date:      2012-09-25 11:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f0aa997ad78b

7199941: test about AES/ECB mode fails
Summary: Fixed the problem of field "blockMode" not having correct value for AES algorithms.
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs11/P11Cipher.java

Changeset: 4fcbddfd97f0
Author:    valeriep
Date:      2012-09-25 11:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4fcbddfd97f0

7199939: DSA 576 and 640 bit keys fail when initializing for No precomputed parameters
Summary: Fixed initialize(int, SecureRandom) call to not error out when no precomputed params available.
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java
! src/share/classes/sun/security/provider/DSAParameterGenerator.java
! src/share/classes/sun/security/provider/ParameterCache.java

Changeset: a58585051c4b
Author:    xuelei
Date:      2012-09-26 21:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a58585051c4b

7200295: CertificateRequest message is wrapping when using large numbers of Certs
Reviewed-by: wetmore

! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/share/classes/sun/security/ssl/Record.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CertRequestOverflow.java

Changeset: 790b81b631ba
Author:    alanb
Date:      2012-09-27 10:30 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/790b81b631ba

7200742: (se) Selector.select does not block when starting Coherence (sol)
Reviewed-by: chegar

! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
+ test/java/nio/channels/Selector/ChangingInterests.java

Changeset: 9e879c0288c2
Author:    andrew
Date:      2012-09-27 17:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9e879c0288c2

7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK.
Summary: Allow OpenJDK to use the unlimited crypto policy.
Reviewed-by: wetmore, ohair

! make/javax/crypto/Makefile

Changeset: 11a5da68673c
Author:    robm
Date:      2012-09-27 22:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11a5da68673c

7199862: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: b3c7a3138c5d
Author:    robm
Date:      2012-09-28 04:39 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3c7a3138c5d

7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 7529cc41e637
Author:    peytoia
Date:      2012-09-28 14:14 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7529cc41e637

7069824: Support for BCP47 locale matching
Reviewed-by: naoto, okutsu

! src/share/classes/java/util/Locale.java
+ src/share/classes/sun/util/locale/LocaleEquivalentMaps.java
+ src/share/classes/sun/util/locale/LocaleMatcher.java
+ test/java/util/Locale/Bug7069824.java
+ test/java/util/Locale/tools/EquivMapsGenerator.java
+ test/java/util/Locale/tools/language-subtag-registry.txt

Changeset: 7e3ef09bb348
Author:    weijun
Date:      2012-09-28 17:15 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7e3ef09bb348

7200682: TEST_BUG: keytool/autotest.sh still has problems with libsoftokn.so
Reviewed-by: alanb, smarks

! test/sun/security/tools/keytool/autotest.sh

Changeset: b8e08f5d255a
Author:    dxu
Date:      2012-09-28 11:14 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8e08f5d255a

6950237: Test java/nio/file/Path/CopyAndMove.java does not work correctly when test dir in on VFAT
Reviewed-by: alanb

! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! test/java/nio/file/Files/CopyAndMove.java

Changeset: 77bf5cde2192
Author:    lana
Date:      2012-09-28 14:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77bf5cde2192

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk
- src/macosx/classes/sun/awt/SunToolkitSubclass.java

Changeset: 0c1c4b185451
Author:    dsamersoff
Date:      2012-09-29 15:44 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c1c4b185451

7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh
Summary: Make test self-terminating and independent to cygwin/mks kill behaviour
Reviewed-by: sspitsyn, alanb

! test/ProblemList.txt
! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java
! test/sun/management/jmxremote/startstop/JMXStartStopTest.java
! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh
! test/sun/management/jmxremote/startstop/REMOTE_TESTING.txt

Changeset: 39cbe256c3d1
Author:    alanb
Date:      2012-10-01 15:36 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39cbe256c3d1

8000269: Cleanup javadoc warnings
Reviewed-by: lancea, darcy, ulfzibis, iris, naoto, dholmes

! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/io/PrintWriter.java
! src/share/classes/java/io/Reader.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/InheritableThreadLocal.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/StrictMath.java
! src/share/classes/java/lang/String.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/ThreadGroup.java
! src/share/classes/java/lang/ThreadLocal.java
! src/share/classes/java/lang/management/ThreadInfo.java
! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/share/classes/java/net/AbstractPlainSocketImpl.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/SocketInputStream.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/nio/channels/Channels.java
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileTime.java
! src/share/classes/java/security/AllPermission.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/security/CodeSource.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/text/CollationElementIterator.java
! src/share/classes/java/text/DigitList.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/RBCollationTables.java
! src/share/classes/java/text/RBTableBuilder.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/java/util/JumboEnumSet.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/RegularEnumSet.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/logging/Logging.java
! src/share/classes/java/util/prefs/XmlSupport.java
! src/share/classes/javax/crypto/CryptoAllPermission.java
! src/share/classes/javax/crypto/CryptoPermission.java
! src/share/classes/javax/crypto/CryptoPolicyParser.java
! src/share/classes/javax/crypto/NullCipherSpi.java
! src/share/classes/javax/management/loading/MLet.java
! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/naming/spi/NamingManager.java
! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java
! src/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/share/classes/javax/sql/ConnectionPoolDataSource.java
! src/share/classes/javax/sql/PooledConnection.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java

Changeset: 75080f572f84
Author:    olagneau
Date:      2012-10-02 10:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75080f572f84

7050528: Improve performance of java.text.DecimalFormat.format() call stack
Reviewed-by: darcy

! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/NumberFormat.java
+ test/java/text/Format/DecimalFormat/FormatMicroBenchmark.java
+ test/java/text/Format/DecimalFormat/GoldenDoubleValues.java
+ test/java/text/Format/DecimalFormat/GoldenFormattedValues.java
+ test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java

Changeset: 041c687c4f40
Author:    psandoz
Date:      2012-10-02 10:36 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/041c687c4f40

7197642: (sl) ServiceLoader.load(null) doesn't throw NPE
Reviewed-by: alanb

! src/share/classes/java/util/ServiceLoader.java
+ test/java/util/ServiceLoader/NPE.java

Changeset: 6750ab947255
Author:    alanb
Date:      2012-10-02 12:23 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6750ab947255

8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit
Reviewed-by: mullan

! test/sun/security/provider/X509Factory/BigCRL.java

Changeset: 4744dc70e5d1
Author:    peytoia
Date:      2012-10-03 15:11 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4744dc70e5d1

7104012: AIOOBE from RuleBasedBreakIterator.lookupState for some suppl. chars
Reviewed-by: okutsu

! src/share/classes/sun/text/SupplementaryCharacterData.java
+ test/java/text/BreakIterator/Bug7104012.java

Changeset: 7fe88d457d85
Author:    dxu
Date:      2012-10-03 09:03 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7fe88d457d85

6910472: Typo in : java.io.ObjectOutputStream.reset() "refered"
Reviewed-by: dholmes, alanb

! src/share/classes/java/io/ObjectOutputStream.java

Changeset: 123db1c28d92
Author:    peytoia
Date:      2012-10-04 11:36 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/123db1c28d92

7196316: Wrong rounding mode in DecimalFormat after deserialization
Reviewed-by: okutsu

! src/share/classes/java/text/DecimalFormat.java
+ test/java/text/Format/DecimalFormat/Bug7196316.java

Changeset: 8692e14b8ea8
Author:    peytoia
Date:      2012-10-04 18:05 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8692e14b8ea8

7201151: Fix Contribution : Java cannot get Windows's IME name correctly
Reviewed-by: okutsu

! src/windows/native/sun/windows/awt_InputMethod.cpp

Changeset: 344f0acff085
Author:    vinnie
Date:      2012-02-14 11:18 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/344f0acff085

7133495: [macosx] KeyChain KeyStore implementation retrieves only one private key entry
Reviewed-by: weijun

! src/macosx/native/apple/security/KeystoreImpl.m
+ test/sun/security/tools/keytool/ListKeychainStore.sh

Changeset: 77af5b4ae4f0
Author:    vinnie
Date:      2012-10-04 11:54 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77af5b4ae4f0

Merge


Changeset: c6a0b13e6efa
Author:    naoto
Date:      2012-10-04 10:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c6a0b13e6efa

7196799: CLDR adapter can not be invoked when region code is specified in Locale
7197573: java/util/Locale/LocaleProviders.sh failed.
Reviewed-by: okutsu

! make/java/java/FILES_java.gmk
! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java
+ src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

Changeset: bba370caafad
Author:    robm
Date:      2012-10-04 19:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bba370caafad

7184932: Remove the temporary Selector usage in the NIO socket adapters
Reviewed-by: alanb

! make/java/nio/mapfile-bsd
! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketAdaptor.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java
! src/solaris/native/sun/nio/ch/Net.c
! src/windows/native/sun/nio/ch/Net.c
+ test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java

Changeset: cd4f181eb666
Author:    naoto
Date:      2012-10-04 21:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd4f181eb666

7200119: Collator.getAvailableLocales() doesn't return Locale.US
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
+ test/java/text/Collator/Bug7200119.java

Changeset: 647424d6cf65
Author:    naoto
Date:      2012-10-04 21:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/647424d6cf65

Merge


Changeset: 88a726a5b2dc
Author:    naoto
Date:      2012-10-05 09:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88a726a5b2dc

7198834: HOST Adapter: one extra empty space in the end of the pattern string
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

Changeset: f65871e75fde
Author:    alanb
Date:      2012-10-06 13:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f65871e75fde

8000354: (props) Properties.storeToXML/loadFromXML need to allow for alternative implementations
Reviewed-by: mchung, forax

! make/java/java/FILES_java.gmk
! make/sun/util/Makefile
! src/share/classes/java/util/Properties.java
+ src/share/classes/sun/util/spi/XmlPropertiesProvider.java
+ src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider
+ src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
- src/share/classes/sun/util/xml/XMLUtils.java
+ test/java/util/Properties/CustomProvider.java
+ test/java/util/Properties/LoadAndStoreXML.java
+ test/java/util/Properties/MyXmlPropertiesProvider.java

Changeset: 92f3a96f3c78
Author:    weijun
Date:      2012-10-08 10:42 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92f3a96f3c78

7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey are set to true
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
+ test/sun/security/krb5/auto/UseCacheAndStoreKey.java

Changeset: d8581143e11d
Author:    lana
Date:      2012-10-08 15:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d8581143e11d

Merge

- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: 61ddb3fd000a
Author:    lana
Date:      2012-10-11 16:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/61ddb3fd000a

Merge

- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: 1ae6420126af
Author:    katleman
Date:      2012-10-18 11:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ae6420126af

Added tag jdk8-b61 for changeset 61ddb3fd000a

! .hgtags


From john.coomes at oracle.com  Thu Oct 18 20:48:10 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Oct 2012 03:48:10 +0000
Subject: hg: hsx/hotspot-main/langtools: 22 new changesets
Message-ID: <20121019034858.E46D347433@hg.openjdk.java.net>

Changeset: 8987971bcb45
Author:    jjg
Date:      2012-09-24 14:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8987971bcb45

7196462: JavacProcessingEnvironment should tolerate BasicJavacTask
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/processing/T7196462.java

Changeset: 99983a4a593b
Author:    mcimadamore
Date:      2012-09-25 11:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/99983a4a593b

7193913: Cleanup Resolve.findMethod
Summary: Refactor method lookup logic in Resolve.findMethod
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: 26d93df3905a
Author:    mcimadamore
Date:      2012-09-25 11:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/26d93df3905a

7194586: Add back-end support for invokedynamic
Summary: Add support for invokedynamic bytecode instruction; includes suppot for generation of all related classfile attributes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/share/classes/com/sun/tools/javac/util/Names.java
+ test/tools/javac/lambda/TestInvokeDynamic.java

Changeset: 2eca84194807
Author:    mcimadamore
Date:      2012-09-25 11:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2eca84194807

7175433: Inference cleanup: add helper class to handle inference variables
Summary: Add class to handle inference variables instantiation and associated info
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/generics/inference/6638712/T6638712c.out
+ test/tools/javac/varargs/6313164/T7175433.java

Changeset: ad2ca2a4ab5e
Author:    mcimadamore
Date:      2012-09-25 11:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ad2ca2a4ab5e

7177306: Regression: unchecked method call does not erase return type
Summary: Spurious extra call to Attr.checkMethod when method call is unchecked
Reviewed-by: jjg, dlsmith

! 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/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/6758789/T6758789b.out
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java
! test/tools/javac/generics/7015430/T7015430.out
! test/tools/javac/generics/7151802/T7151802.out
+ test/tools/javac/generics/inference/7177306/T7177306a.java
+ test/tools/javac/generics/inference/7177306/T7177306a.out
+ test/tools/javac/generics/inference/7177306/T7177306b.java
+ test/tools/javac/generics/inference/7177306/T7177306b.out
+ test/tools/javac/generics/inference/7177306/T7177306c.java
+ test/tools/javac/generics/inference/7177306/T7177306d.java
+ test/tools/javac/generics/inference/7177306/T7177306e.java
+ test/tools/javac/generics/inference/7177306/T7177306e.out

Changeset: 0e5899f09dab
Author:    jjg
Date:      2012-09-25 13:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0e5899f09dab

7193657: provide internal ArrayUtils class to simplify common usage of arrays in javac
Reviewed-by: mcimadamore, jjg
Contributed-by: vicenterz at yahoo.es

! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/javac/api/MultiTaskListener.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/file/Locations.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java
+ src/share/classes/com/sun/tools/javac/util/ArrayUtils.java
! src/share/classes/com/sun/tools/javac/util/Bits.java
! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java
! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java
! src/share/classes/com/sun/tools/javap/StackMapWriter.java

Changeset: 99d23c0ef8ee
Author:    jjg
Date:      2012-09-25 13:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/99d23c0ef8ee

7196464: upgrade JavaCompiler.shouldStopPolicy to accomodate policies in face of error and no error
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java

Changeset: db36841709e4
Author:    mcimadamore
Date:      2012-09-26 14:22 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/db36841709e4

7188968: New instance creation expression using diamond is checked twice
Summary: Unify method and constructor check logic
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/6857948/T6857948.out
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/generics/diamond/7002837/T7002837.java
+ test/tools/javac/generics/diamond/7002837/T7002837.out
+ test/tools/javac/generics/diamond/7188968/T7188968.java
+ test/tools/javac/generics/diamond/7188968/T7188968.out
! test/tools/javac/positions/T6264029.out

Changeset: 1a65d6565b45
Author:    mcimadamore
Date:      2012-09-28 16:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1a65d6565b45

8000233: Fix issues in recent push
Summary: Forgot to incorporate review comments in pushed changesets
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/share/classes/com/sun/tools/javac/util/Names.java

Changeset: f1e6b361a329
Author:    mcimadamore
Date:      2012-09-28 18:50 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f1e6b361a329

8000241: langtools doesn't build
Summary: bad merge with langtools tip caused build glitch
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Pool.java
! test/tools/javac/lambda/TestInvokeDynamic.java

Changeset: 73312ec2cf7c
Author:    jfranck
Date:      2012-09-28 11:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/73312ec2cf7c

7199925: Separate compilation breaks check that elements have a default for the containing annotation
Reviewed-by: jjg, mcimadamore

! 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/resources/compiler.properties

Changeset: e77841f2c74b
Author:    lana
Date:      2012-09-28 14:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e77841f2c74b

Merge


Changeset: 20e4a54b1629
Author:    ksrini
Date:      2012-09-29 09:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/20e4a54b1629

7198582: (java) Minor refactor of JavacParser
Reviewed-by: jjg, ksrini
Contributed-by: jan.lahoda at oracle.com

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javap/CodeWriter.java

Changeset: 1408af4cd8b0
Author:    mcimadamore
Date:      2012-10-04 13:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1408af4cd8b0

7177387: Add target-typing support in method context
Summary: Add support for deferred types and speculative attribution
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeTags.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/AttrContext.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/conditional/Conditional.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/IncompatibleTypesInConditional.java
+ test/tools/javac/diags/examples/TypeConditional.java

Changeset: 573ceb23beeb
Author:    mcimadamore
Date:      2012-10-05 14:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/573ceb23beeb

7177385: Add attribution support for lambda expressions
Summary: Add support for function descriptor lookup, functional interface inference and lambda expression type-checking
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Printer.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/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/6402516/TestLocalElements.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java
+ test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java
+ test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java
! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java
! test/tools/javac/diags/examples/CatchWithoutTry.java
+ test/tools/javac/diags/examples/CyclicInference.java
+ test/tools/javac/diags/examples/IncompatibleAbstracts.java
+ test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java
+ test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java
+ test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java
+ test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
+ test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java
+ test/tools/javac/diags/examples/MissingReturnValueFragment.java
+ test/tools/javac/diags/examples/NoAbstracts.java
+ test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java
+ test/tools/javac/diags/examples/NotAFunctionalIntf.java
+ test/tools/javac/diags/examples/PotentialLambdaFound.java
- test/tools/javac/diags/examples/TypeConditional.java
+ test/tools/javac/diags/examples/UnexpectedLambda.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/typeAnnotations/newlocations/BasicTest.out

Changeset: d604fd09480b
Author:    bpatel
Date:      2012-10-05 14:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d604fd09480b

7132631: The help-doc.html generates an invalid link to constant-values.html
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
+ test/com/sun/javadoc/testHelpFile/TestHelpFile.java

Changeset: ef88ae455c88
Author:    bpatel
Date:      2012-10-05 14:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ef88ae455c88

7068595: html files in class-use dir do not get loaded correctly when Frames link is clicked
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! test/com/sun/javadoc/testUseOption/TestUseOption.java

Changeset: f4e45397722a
Author:    bpatel
Date:      2012-10-05 14:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f4e45397722a

4696488: javadoc doesn't handle UNC paths for destination directory
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
+ test/tools/javadoc/T4696488.java

Changeset: d4b3cb1ece84
Author:    mcimadamore
Date:      2012-10-06 10:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d4b3cb1ece84

7177386: Add attribution support for method references
Summary: Add type-checking/lookup routines for method references
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.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/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! test/tools/javac/6758789/T6758789a.out
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/7132880/T7132880.out
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/T6326754.out
! test/tools/javac/diags/CheckResourceKeys.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/CantAccessInnerClsConstr.java
+ test/tools/javac/diags/examples/CantApplySymbolFragment.java
+ test/tools/javac/diags/examples/CantApplySymbolsFragment.java
+ test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java
+ test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java
! test/tools/javac/diags/examples/CyclicInference.java
! test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java
! test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java
! test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java
+ test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java
+ test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java
! test/tools/javac/diags/examples/InferArgsLengthMismatch.java
! test/tools/javac/diags/examples/InferNoConformingAssignment.java
! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java
! test/tools/javac/diags/examples/InferredDoNotConformToEq.java
! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/MethodReferencesNotSupported.java
! test/tools/javac/diags/examples/NoArgs.java
+ test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
! test/tools/javac/diags/examples/NotApplicableMethodFound.java
+ test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java
+ test/tools/javac/diags/examples/RefAmbiguousFragment.java
+ test/tools/javac/diags/examples/UnexpectedMref.java
! test/tools/javac/diags/examples/VarargsArgumentMismatch.java
! test/tools/javac/diags/examples/VerboseResolveMulti1.java
! test/tools/javac/diags/examples/WhereCaptured.java
! test/tools/javac/diags/examples/WhereCaptured1.java
! test/tools/javac/diags/examples/WhereTypeVar.java
! test/tools/javac/generics/7034511/T7034511a.out
! test/tools/javac/generics/7034511/T7034511b.out
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712a.out
! test/tools/javac/generics/inference/6638712/T6638712c.out
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6838943/T6838943.out
! test/tools/javac/generics/inference/7086586/T7086586.out
! test/tools/javac/generics/inference/7177306/T7177306b.out
! test/tools/javac/lambda/MethodReferenceParserTest.java
! test/tools/javac/quid/T6999438.out
! test/tools/javac/varargs/6313164/T6313164.out

Changeset: aa3ef5c09b1b
Author:    lana
Date:      2012-10-08 15:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/aa3ef5c09b1b

Merge


Changeset: 26020b247ad3
Author:    lana
Date:      2012-10-11 17:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/26020b247ad3

Merge


Changeset: b47bb81ba962
Author:    katleman
Date:      2012-10-18 11:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b47bb81ba962

Added tag jdk8-b61 for changeset 26020b247ad3

! .hgtags


From keith.mcguigan at oracle.com  Fri Oct 19 04:24:11 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Fri, 19 Oct 2012 07:24:11 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <5075AC78.3030702@oracle.com>
References: <5075AC78.3030702@oracle.com>
Message-ID: <5081385B.2010207@oracle.com>


Anyone?

On 10/10/2012 1:12 PM, Keith McGuigan wrote:
> Hello,
>
> I'd like any review of the code which implements default methods in the
> JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and
> tracked by CR 7200776.
>
> The design and implementation is described in this short document:
> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>
> And the code is here:
> http://cr.openjdk.java.net/~kamg/default_methods/
>
> Any review (even partial) would be appreciated.  Thanks!
>
> --
> - Keith

From alejandro.murillo at oracle.com  Fri Oct 19 05:55:06 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 19 Oct 2012 12:55:06 +0000
Subject: hg: hsx/hsx24/hotspot: 8001174: new hotspot build - hs24-b23
Message-ID: <20121019125512.513D847455@hg.openjdk.java.net>

Changeset: 17e506a2f436
Author:    amurillo
Date:      2012-10-19 02:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/17e506a2f436

8001174: new hotspot build - hs24-b23
Reviewed-by: jcoomes

! make/hotspot_version


From coleen.phillimore at oracle.com  Fri Oct 19 10:23:04 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 19 Oct 2012 13:23:04 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <5081385B.2010207@oracle.com>
References: <5075AC78.3030702@oracle.com> <5081385B.2010207@oracle.com>
Message-ID: <50818C78.2040308@oracle.com>


bytecodeAssembler.hpp

Can you add to the top comment about why someone would use this class, 
and why you are using it.  I think if we have other generated methods, 
this is a useful class for people to add to rather than write their own 
in a different way.

BytecodeCPEntry is a VALUE_OBJ_CLASS_SPEC  (currently)

defaultMethods.cpp

line 775 - I think this  is the ResourceMark that's keeping everything 
alive right.  I think you should have a comment here that everything is 
resource allocated and not to add ResourceMark's in odd places.

KeepAliveRegistrar - I think this is a good solution to the problem of 
redefining classes while you are processing them.  It usually isn't a 
problem for the class you are finding default methods for because it's 
not in the system dictionary yet.  If a super class is redefined while 
you are processing the methods can it add an implementation for default 
or abstract method?   I think this isn't possible today until extended 
class redefinition.

783 - I think you want a ResourcMark() in here and 657.   These names 
printed might take up enough space for you to worry about running out 
while this is code is executed.

647 - if m is an overpass, why do you lookup the method again and why 
can it get a different answer.   A comment why would help because I 
don't know.

81 - seems like super_of() belongs in instanceKlass.hpp - just change 
the type of super() to return InstanceKlass.   Isn't _super always 
InstanceKlass (we can add this as another cleanup, but if you move your 
function we'll get it too in the cleanup).

48 - a nice comment about what these PseudoScopeMarks are for would be 
useful.   It's so you don't iterate recursively I think.

86 - print_slot and print_method seem like they should be under ifndef 
PRODUCT    And PrintHierarchy should be #ifndef PRODUCT rather than 
ASSERT.   Not that there's a good solid rule around these two 
preprocessor directives, but make sure optimized builds.

I am looking at HiearchyVisitor::run now.  I like how it perfectly fits 
on a page for me.   This looks really good so far.

Thanks,
Coleen

On 10/19/2012 7:24 AM, Keith McGuigan wrote:
>
> Anyone?
>
> On 10/10/2012 1:12 PM, Keith McGuigan wrote:
>> Hello,
>>
>> I'd like any review of the code which implements default methods in the
>> JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and
>> tracked by CR 7200776.
>>
>> The design and implementation is described in this short document:
>> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>>
>> And the code is here:
>> http://cr.openjdk.java.net/~kamg/default_methods/
>>
>> Any review (even partial) would be appreciated.  Thanks!
>>
>> -- 
>> - Keith

From karen.kinnear at oracle.com  Fri Oct 19 12:08:37 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 19 Oct 2012 15:08:37 -0400
Subject: Code review request: 7199092 NMT: NMT needs to deal overlapped
	virtual memory ranges
In-Reply-To: <50805058.6050109@oracle.com>
References: <50660A67.1010901@oracle.com> <50805058.6050109@oracle.com>
Message-ID: <52922923-4A89-44D2-A582-85D50C0EB9E2@oracle.com>

Zhengyu,

Thank you for the fixes. I am impressed you found and fixed so many difficult issues.
This looks really good.

A couple of minor questions/comments:

1) os_solaris.cpp
Did you add the new record_virtual_memory_reserve because you were running into the case in which
the anon_mmap returns a value that does not match the requested address and
therefore we call unmap_memory which already calls record_virtual_memory_release? 

In os_linux.cpp, os_bsd.cpp, this is handled by calling anon_munmap inside pd_attempt_reserve_memory_at,
rather than calling out to the platform-independent unmap_memory. So unless you have a strong reason to do
this differently on Solaris, I would recommend that you change it to call pd_unmap_memory instead.


2) thread.cpp
line 4077 "became" -> "becomes"
 line 4078 "not" ->"no" ,"walk" -> "walks"
Question - do you need to do the MemTracker::thread_exiting before the set_safepoint_visible(false) call?

3) I see you added record_stack_base_and_size for the AttachListener.
I am wondering if we also need this for other internal threads:
  compiler threads, low memory detector, service thread, jvmti agent threads, signal handler, 3 JFR threads
--- we should add to our cleanup wishlist to clean up creating internal threads so we can share more common code
and include this as part of that if you want to have this done separately.

4) I don't understand the assertion in memTracker.hpp release_thread_stack,
assert (!thr->is_Java_thread(), "too early") ?

5) memSnapshot.hpp
line 115: "where is" -> "where"
Thank you for simplifying this to just pass in one address

thanks,
Karen




On Oct 18, 2012, at 2:54 PM, Zhengyu Gu wrote:

> The new webrev reflects some suggestions from previous code review, along with:
> 
> 1. Caught more cases that virtual memory operations do not go through os api, which cause mis-matched records that confuse NMT.
> 2. Fixed a bug that JavaThread releases its per-thread recorder too later, so that the record could be misplaced in wrong generation.
> 3. Cleanup. Removed some dead code and unnecessary assertions
> 4. Fixed racing conditions that could mis-count arena sizes. When ResourceMark or HandleMark resets, it should reset arena size first, before release memory chunks.
> 5. Fixed missing call to record native stack on AttachListener thread.
> 6.  Removed unused Arena constructor.
> 
> Webrev: http://cr.openjdk.java.net/~zgu/7199092/webrev.01/
> 
> Thanks,
> 
> -Zhengyu
> 
> 
> On 9/28/2012 4:36 PM, Zhengyu Gu wrote:
>> With PermGen removal integration, virtual memory usage patterns have changed vs. earlier. NMT can not longer just track reserved memory regions, and assume commits and uncommits are performed from the tail end.
>> 
>> NMT now tracks committed memory regions, alone with reserved memory regions, a virtual memory map is maintained by NMT, and it is reported with detail tracking data.
>> 
>> The changes also include some cleanup and enhanced assertion, etc.
>> 
>> CR: http://bugs.sun.com/view_bug.do?bug_id=7199092
>> Webrev:  http://cr.openjdk.java.net/~zgu/7199092/webrev.00/
>> 
>> 
>> An example of virtual memory map:
>> 
>> Virtual memory map:
>> 
>> [0x8f17e000 - 0x8f364000] reserved 1944KB for Thread Stack
>>        from [Thread::record_stack_base_and_size()+0x120]
>>    [0x8f17e000 - 0x8f364000] committed 1944KB from [Thread::record_stack_base_and_size()+0x120]
>> 
>> [0x8f389000 - 0x8f680000] reserved 3036KB for Thread Stack
>>        from [Thread::record_stack_base_and_size()+0x120]
>>    [0x8f389000 - 0x8f680000] committed 3036KB from [Thread::record_stack_base_and_size()+0x120]
>> 
>> [0x8f7dd000 - 0x8f900000] reserved 1164KB for Thread Stack
>>        from [Thread::record_stack_base_and_size()+0x120]
>>    [0x8f7dd000 - 0x8f900000] committed 1164KB from [Thread::record_stack_base_and_size()+0x120]
>> 
>> [0x8fa20000 - 0x8faa1000] reserved 516KB for Thread Stack
>>        from [Thread::record_stack_base_and_size()+0x120]
>>    [0x8fa20000 - 0x8faa1000] committed 516KB from [Thread::record_stack_base_and_size()+0x120]
>> 
>> [0x8fd30000 - 0x914b8000] reserved 24096KB for GC
>>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>    [0x8fd30000 - 0x914b8000] committed 24096KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>> 
>> [0x914b8000 - 0x916bc000] reserved 2064KB for Thread Stack
>>        from [Thread::record_stack_base_and_size()+0x120]
>>    [0x914b8000 - 0x916bc000] committed 2064KB from [Thread::record_stack_base_and_size()+0x120]
>> 
>> [0x916bc000 - 0x91860000] reserved 1680KB for GC
>>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>    [0x916bc000 - 0x916c7000] committed 44KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>    [0x91764000 - 0x9176f000] committed 44KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>>    [0x9180b000 - 0x91811000] committed 24KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>>    [0x9185f000 - 0x91860000] committed 4KB from [CardTableModRefBS::CardTableModRefBS(MemRegion, int)+0x2a0]
>> 
>> [0x91860000 - 0xb1060000] reserved 516096KB for Java Heap
>>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x190]
>>    [0x91860000 - 0x92d50000] committed 21440KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>    [0xa6710000 - 0xa7180000] committed 10688KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>    [0xb0e60000 - 0xb0ea9000] committed 292KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>> 
>> [0xb1069000 - 0xb71e9000] reserved 99840KB for Code
>>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>    [0xb1069000 - 0xb1072000] committed 36KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>    [0xb11e9000 - 0xb1429000] committed 2304KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>> 
>> [0xb71e9000 - 0xb77e9000] reserved 6144KB for Class
>>        from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>    [0xb71e9000 - 0xb750a000] committed 3204KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>> 
>> [0xb77e9000 - 0xb783a000] reserved 324KB for Thread Stack
>>        from [Thread::record_stack_base_and_size()+0x120]
>>    [0xb77e9000 - 0xb783a000] committed 324KB from [Thread::record_stack_base_and_size()+0x120]
>> 
>> Tests performed:
>> - JPRT tests
>> 
>> - Linux 32 bit:
>>    vm.quick.testlist
>>    nsk.stress
>>    runtime.ParallelClassLoading
>>    nsk.quick-jdi.testlist
>>    nsk.quick-jvmti.testlist
>> 
>> - Solaris x64
>>    vm.quick.testlist
>>    runtime.ParallelClassLoading
>>    nsk.stress.jck60
>> 
>> - Solaris sparcv9
>>    vm.quick.testlist
>>    runtime.ParallelClassLoading
>>    nsk.stress.jck60
>> 
>> 
>> Thanks,
>> 
>> -Zhengyu


From zhengyu.gu at oracle.com  Fri Oct 19 12:37:11 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 19 Oct 2012 15:37:11 -0400
Subject: Code review request: 7199092  NMT: NMT needs to deal overlapped
	virtual memory ranges
In-Reply-To: <52922923-4A89-44D2-A582-85D50C0EB9E2@oracle.com>
References: <50660A67.1010901@oracle.com> <50805058.6050109@oracle.com>
	<52922923-4A89-44D2-A582-85D50C0EB9E2@oracle.com>
Message-ID: <5081ABE7.40004@oracle.com>

Hi Karen,

Thank you for reviewing the code.

On 10/19/2012 3:08 PM, Karen Kinnear wrote:
> Zhengyu,
>
> Thank you for the fixes. I am impressed you found and fixed so many difficult issues.
> This looks really good.
>
> A couple of minor questions/comments:
>
> 1) os_solaris.cpp
> Did you add the new record_virtual_memory_reserve because you were running into the case in which
> the anon_mmap returns a value that does not match the requested address and
> therefore we call unmap_memory which already calls record_virtual_memory_release?
>
> In os_linux.cpp, os_bsd.cpp, this is handled by calling anon_munmap inside pd_attempt_reserve_memory_at,
> rather than calling out to the platform-independent unmap_memory. So unless you have a strong reason to do
> this differently on Solaris, I would recommend that you change it to call pd_unmap_memory instead.
Yes, this is an alternative, I will take this one.
>
> 2) thread.cpp
> line 4077 "became" ->  "becomes"
>   line 4078 "not" ->"no" ,"walk" ->  "walks"
Thanks.
> Question - do you need to do the MemTracker::thread_exiting before the set_safepoint_visible(false) call?
Yes. Only after safepoint visible = false, the thread no longer writes 
records to per-thread recorder, so we can safely queue the recorder.
> 3) I see you added record_stack_base_and_size for the AttachListener.
> I am wondering if we also need this for other internal threads:
>    compiler threads, low memory detector, service thread, jvmti agent threads, signal handler, 3 JFR threads
> --- we should add to our cleanup wishlist to clean up creating internal threads so we can share more common code
> and include this as part of that if you want to have this done separately.
I think we do in most cases, if not all. I will walk the code again to 
ensure that is the case.
> 4) I don't understand the assertion in memTracker.hpp release_thread_stack,
> assert (!thr->is_Java_thread(), "too early") ?
>
Thread stack is managed at Thread level, the assertion is to make sure 
that the stack info is not released prematurely.

> 5) memSnapshot.hpp
> line 115: "where is" ->  "where"
> Thank you for simplifying this to just pass in one address
>
> thanks,
Thanks,

-Zhengyu

> Karen
>
>
>
>
> On Oct 18, 2012, at 2:54 PM, Zhengyu Gu wrote:
>
>> The new webrev reflects some suggestions from previous code review, along with:
>>
>> 1. Caught more cases that virtual memory operations do not go through os api, which cause mis-matched records that confuse NMT.
>> 2. Fixed a bug that JavaThread releases its per-thread recorder too later, so that the record could be misplaced in wrong generation.
>> 3. Cleanup. Removed some dead code and unnecessary assertions
>> 4. Fixed racing conditions that could mis-count arena sizes. When ResourceMark or HandleMark resets, it should reset arena size first, before release memory chunks.
>> 5. Fixed missing call to record native stack on AttachListener thread.
>> 6.  Removed unused Arena constructor.
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/7199092/webrev.01/
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 9/28/2012 4:36 PM, Zhengyu Gu wrote:
>>> With PermGen removal integration, virtual memory usage patterns have changed vs. earlier. NMT can not longer just track reserved memory regions, and assume commits and uncommits are performed from the tail end.
>>>
>>> NMT now tracks committed memory regions, alone with reserved memory regions, a virtual memory map is maintained by NMT, and it is reported with detail tracking data.
>>>
>>> The changes also include some cleanup and enhanced assertion, etc.
>>>
>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7199092
>>> Webrev:  http://cr.openjdk.java.net/~zgu/7199092/webrev.00/
>>>
>>>
>>> An example of virtual memory map:
>>>
>>> Virtual memory map:
>>>
>>> [0x8f17e000 - 0x8f364000] reserved 1944KB for Thread Stack
>>>         from [Thread::record_stack_base_and_size()+0x120]
>>>     [0x8f17e000 - 0x8f364000] committed 1944KB from [Thread::record_stack_base_and_size()+0x120]
>>>
>>> [0x8f389000 - 0x8f680000] reserved 3036KB for Thread Stack
>>>         from [Thread::record_stack_base_and_size()+0x120]
>>>     [0x8f389000 - 0x8f680000] committed 3036KB from [Thread::record_stack_base_and_size()+0x120]
>>>
>>> [0x8f7dd000 - 0x8f900000] reserved 1164KB for Thread Stack
>>>         from [Thread::record_stack_base_and_size()+0x120]
>>>     [0x8f7dd000 - 0x8f900000] committed 1164KB from [Thread::record_stack_base_and_size()+0x120]
>>>
>>> [0x8fa20000 - 0x8faa1000] reserved 516KB for Thread Stack
>>>         from [Thread::record_stack_base_and_size()+0x120]
>>>     [0x8fa20000 - 0x8faa1000] committed 516KB from [Thread::record_stack_base_and_size()+0x120]
>>>
>>> [0x8fd30000 - 0x914b8000] reserved 24096KB for GC
>>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>>     [0x8fd30000 - 0x914b8000] committed 24096KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>>
>>> [0x914b8000 - 0x916bc000] reserved 2064KB for Thread Stack
>>>         from [Thread::record_stack_base_and_size()+0x120]
>>>     [0x914b8000 - 0x916bc000] committed 2064KB from [Thread::record_stack_base_and_size()+0x120]
>>>
>>> [0x916bc000 - 0x91860000] reserved 1680KB for GC
>>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>>     [0x916bc000 - 0x916c7000] committed 44KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>>     [0x91764000 - 0x9176f000] committed 44KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>>>     [0x9180b000 - 0x91811000] committed 24KB from [CardTableModRefBS::resize_covered_region(MemRegion)+0xebf]
>>>     [0x9185f000 - 0x91860000] committed 4KB from [CardTableModRefBS::CardTableModRefBS(MemRegion, int)+0x2a0]
>>>
>>> [0x91860000 - 0xb1060000] reserved 516096KB for Java Heap
>>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x190]
>>>     [0x91860000 - 0x92d50000] committed 21440KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>>     [0xa6710000 - 0xa7180000] committed 10688KB from [PSVirtualSpace::expand_by(unsigned int)+0x95]
>>>     [0xb0e60000 - 0xb0ea9000] committed 292KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>>
>>> [0xb1069000 - 0xb71e9000] reserved 99840KB for Code
>>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>>     [0xb1069000 - 0xb1072000] committed 36KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>>     [0xb11e9000 - 0xb1429000] committed 2304KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>>
>>> [0xb71e9000 - 0xb77e9000] reserved 6144KB for Class
>>>         from [ReservedSpace::initialize(unsigned int, unsigned int, bool, char*, unsigned int, bool)+0x555]
>>>     [0xb71e9000 - 0xb750a000] committed 3204KB from [VirtualSpace::initialize(ReservedSpace, unsigned int)+0x3e8]
>>>
>>> [0xb77e9000 - 0xb783a000] reserved 324KB for Thread Stack
>>>         from [Thread::record_stack_base_and_size()+0x120]
>>>     [0xb77e9000 - 0xb783a000] committed 324KB from [Thread::record_stack_base_and_size()+0x120]
>>>
>>> Tests performed:
>>> - JPRT tests
>>>
>>> - Linux 32 bit:
>>>     vm.quick.testlist
>>>     nsk.stress
>>>     runtime.ParallelClassLoading
>>>     nsk.quick-jdi.testlist
>>>     nsk.quick-jvmti.testlist
>>>
>>> - Solaris x64
>>>     vm.quick.testlist
>>>     runtime.ParallelClassLoading
>>>     nsk.stress.jck60
>>>
>>> - Solaris sparcv9
>>>     vm.quick.testlist
>>>     runtime.ParallelClassLoading
>>>     nsk.stress.jck60
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu

From alejandro.murillo at oracle.com  Fri Oct 19 13:29:43 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 19 Oct 2012 20:29:43 +0000
Subject: hg: hsx/hsx25/hotspot: 16 new changesets
Message-ID: <20121019203021.3B69247460@hg.openjdk.java.net>

Changeset: fcbdaeb69946
Author:    katleman
Date:      2012-10-18 11:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fcbdaeb69946

Added tag jdk8-b61 for changeset 4547dc71db76

! .hgtags

Changeset: 58fbf2da3c16
Author:    amurillo
Date:      2012-10-12 14:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/58fbf2da3c16

8000834: new hotspot build - hs25-b06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 8a5ea0a9ccc4
Author:    johnc
Date:      2012-10-06 01:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8a5ea0a9ccc4

7127708: G1: change task num types from int to uint in concurrent mark
Summary: Change the type of various task num fields, parameters etc to unsigned and rename them to be more consistent with the other collectors. Code changes were also reviewed by Vitaly Davidovich.
Reviewed-by: johnc
Contributed-by: Kaushik Srenevasan <kaushik at twitter.com>

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp

Changeset: 04155d9c8c76
Author:    johnc
Date:      2012-10-08 09:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/04155d9c8c76

8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file
Summary: Missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on().
Reviewed-by: azeemj, jmasa
Contributed-by: Mikael Gerdin <mikael.gerdin at oracle.com>

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

Changeset: dd2b66d09ccd
Author:    stefank
Date:      2012-10-09 22:12 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dd2b66d09ccd

8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn
Summary: Treat the oops in invoke_method_table() as strong roots when ClassUnloading is enabled.
Reviewed-by: kamg, coleenp

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

Changeset: 4202510ee0fe
Author:    johnc
Date:      2012-10-15 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4202510ee0fe

8000831: Heap verification output incorrect/incomplete
Summary: Restore non-silent output of heap verification.
Reviewed-by: ysr, brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/utilities/debug.cpp

Changeset: 633ba56cb013
Author:    jmasa
Date:      2012-10-17 13:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/633ba56cb013

Merge

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/memory/universe.hpp

Changeset: bdb5f8c9978b
Author:    coleenp
Date:      2012-10-10 17:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bdb5f8c9978b

7199068: NPG: SharedSkipVerify is meaningless
Summary: Remove the SharedSkipVerify flag
Reviewed-by: kamg, sspitsyn, coleenp
Contributed-by: harold.seigel at oracle.com

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp

Changeset: 48a75d2640a5
Author:    kamg
Date:      2012-10-11 14:27 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/48a75d2640a5

7054345: Support version 52.0 class file in HotSpot
Summary: Accept classfiles with major version 52
Reviewed-by: coleenp, acorn

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

Changeset: e0ea0e94c23c
Author:    kevinw
Date:      2012-10-15 16:48 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e0ea0e94c23c

7195151: Multiplatform tescase for 6929067
Reviewed-by: kamg, kvn

! test/runtime/6929067/Test6929067.sh

Changeset: e52361627b65
Author:    coleenp
Date:      2012-10-15 22:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e52361627b65

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 045cb62046a7
Author:    rbackman
Date:      2012-08-28 15:15 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/045cb62046a7

7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives
Reviewed-by: dholmes, dcubed

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

Changeset: 7b5885dadbdc
Author:    nloodin
Date:      2012-10-17 17:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7b5885dadbdc

8000617: It should be possible to allocate memory without the VM dying.
Reviewed-by: coleenp, kamg

! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/resourceArea.cpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: e8c79c2ba3f3
Author:    coleenp
Date:      2012-10-18 12:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e8c79c2ba3f3

Merge


Changeset: d0337c31c8be
Author:    amurillo
Date:      2012-10-19 11:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d0337c31c8be

Merge


Changeset: dccd40de8db1
Author:    amurillo
Date:      2012-10-19 11:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dccd40de8db1

Added tag hs25-b06 for changeset d0337c31c8be

! .hgtags


From keith.mcguigan at oracle.com  Fri Oct 19 13:50:09 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Fri, 19 Oct 2012 16:50:09 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <50818C78.2040308@oracle.com>
References: <5075AC78.3030702@oracle.com> <5081385B.2010207@oracle.com>
	<50818C78.2040308@oracle.com>
Message-ID: <5081BD01.3030900@oracle.com>



On 10/19/2012 1:23 PM, Coleen Phillimore wrote:
>
> bytecodeAssembler.hpp
>
> Can you add to the top comment about why someone would use this class,
> and why you are using it.  I think if we have other generated methods,
> this is a useful class for people to add to rather than write their own
> in a different way.

No idea why someone else would use this class, but I'll add a comment 
about what I'm doing with it.

> BytecodeCPEntry is a VALUE_OBJ_CLASS_SPEC  (currently)

Fixed.

> defaultMethods.cpp
>
> line 775 - I think this  is the ResourceMark that's keeping everything
> alive right.  I think you should have a comment here that everything is
> resource allocated and not to add ResourceMark's in odd places.

Ok.

> KeepAliveRegistrar - I think this is a good solution to the problem of
> redefining classes while you are processing them.  It usually isn't a
> problem for the class you are finding default methods for because it's
> not in the system dictionary yet.  If a super class is redefined while
> you are processing the methods can it add an implementation for default
> or abstract method?   I think this isn't possible today until extended
> class redefinition.

Right, I don't think that's possible yet, and yes the current class is 
protected from redefinition because it isn't published yet.  So it's 
really the supertypes that this is protecting.

>
> 783 - I think you want a ResourcMark() in here and 657.   These names
> printed might take up enough space for you to worry about running out
> while this is code is executed.

This is debug-only code (the flag is DEVELOP), so I'm less worried about 
running out of memory.  I'd rather keep this code ResourceMark-clean so 
that only the top-level mark is used (see your worry above).

> 647 - if m is an overpass, why do you lookup the method again and why
> can it get a different answer.   A comment why would help because I
> don't know.

I'll add a comment.  The reason is that we're looking for methods which 
would have been mirandas if not for the default method processing on our 
superclass(es).  We can tell which would have been mirandas because they 
are marked as 'is_overpass'.  But that's not quite enough because we 
might have implemented the method ourselves in the current class. 
That's what the second check looks for.

> 81 - seems like super_of() belongs in instanceKlass.hpp - just change
> the type of super() to return InstanceKlass.   Isn't _super always
> InstanceKlass (we can add this as another cleanup, but if you move your
> function we'll get it too in the cleanup).

There is "Klass* InstanceKlass::java_super() const { return super(); }"
I'll try converting that to return an InstanceKlass* instead and see 
what breaks.  If it's not much, I'll just use java_super() in my code. 
Otherwise, I'll add a new method in InstanceKlass.  Maybe 
instance_super()?  Ugly but maybe something like that.

> 48 - a nice comment about what these PseudoScopeMarks are for would be
> useful.   It's so you don't iterate recursively I think.

Well, it's because I don't iterate recursively that I can't use regular 
marks and scope.  I'll add a comment.

> 86 - print_slot and print_method seem like they should be under ifndef
> PRODUCT    And PrintHierarchy should be #ifndef PRODUCT rather than
> ASSERT.   Not that there's a good solid rule around these two
> preprocessor directives, but make sure optimized builds.

Will do.  I suppose I can be more aggressive at cutting out more of this 
other printing code for product builds, too.  Yucky #ifdefs, but oh well...

> I am looking at HiearchyVisitor::run now.  I like how it perfectly fits
> on a page for me.   This looks really good so far.

Cool!  Keep the comments coming.  And thanks!

--
- Keith

From alejandro.murillo at oracle.com  Fri Oct 19 15:21:56 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 19 Oct 2012 22:21:56 +0000
Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets
Message-ID: <20121019222215.41CC547463@hg.openjdk.java.net>

Changeset: fcbdaeb69946
Author:    katleman
Date:      2012-10-18 11:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fcbdaeb69946

Added tag jdk8-b61 for changeset 4547dc71db76

! .hgtags

Changeset: d0337c31c8be
Author:    amurillo
Date:      2012-10-19 11:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d0337c31c8be

Merge


Changeset: dccd40de8db1
Author:    amurillo
Date:      2012-10-19 11:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dccd40de8db1

Added tag hs25-b06 for changeset d0337c31c8be

! .hgtags

Changeset: d0e7716b179e
Author:    amurillo
Date:      2012-10-19 11:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d0e7716b179e

8001176: new hotspot build - hs25-b07
Reviewed-by: jcoomes

! make/hotspot_version


From alejandro.murillo at oracle.com  Fri Oct 19 16:39:32 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 19 Oct 2012 23:39:32 +0000
Subject: hg: hsx/hsx24/hotspot: 8001192: allow duplicate bug ids in hs24
Message-ID: <20121019233937.4043447466@hg.openjdk.java.net>

Changeset: 81d17d9ab7c9
Author:    amurillo
Date:      2012-10-19 16:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/81d17d9ab7c9

8001192: allow duplicate bug ids in hs24
Reviewed-by: jcoomes

! .jcheck/conf


From vladimir.kozlov at oracle.com  Sat Oct 20 08:40:46 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sat, 20 Oct 2012 08:40:46 -0700
Subject: Result: New HSX Committer: Nils Eliasson
Message-ID: <5082C5FE.8060404@oracle.com>

Voting for Nils Eliasson [1] is now closed.

Yes: 18
Veto: 0
Abstain: 0

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

Vladimir Kozlov

[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/006762.html
[2] http://openjdk.java.net/bylaws#lazy-consensus



From john.coomes at oracle.com  Sat Oct 20 16:46:05 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Sat, 20 Oct 2012 23:46:05 +0000
Subject: hg: hsx/hsx24/hotspot: 366 new changesets
Message-ID: <20121021000324.329F847479@hg.openjdk.java.net>

Changeset: fe189d4a44e9
Author:    katleman
Date:      2011-05-25 13:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fe189d4a44e9

7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles
Reviewed-by: ohair, trims

! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java
! make/linux/README
! make/windows/projectfiles/kernel/Makefile
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/os_cpu/solaris_sparc/vm/solaris_sparc.s
! src/share/tools/hsdis/README
! src/share/vm/gc_implementation/g1/heapRegionSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegionSets.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/utilities/yieldingWorkgroup.cpp

Changeset: d920485ae93b
Author:    schien
Date:      2011-05-26 20:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d920485ae93b

Added tag jdk7-b144 for changeset fe189d4a44e9

! .hgtags

Changeset: 2d4b2b833d29
Author:    coleenp
Date:      2011-05-27 15:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2d4b2b833d29

7033141: assert(has_cp_cache(i)) failed: oob
Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache.
Reviewed-by: dcubed, acorn, never

! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/methodHandleWalk.cpp

Changeset: 8cbcd406c42e
Author:    ysr
Date:      2011-05-27 15:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8cbcd406c42e

7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557
Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block.
Reviewed-by: brutisso, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/blockOffsetTable.cpp

Changeset: b36598cf2c62
Author:    jcoomes
Date:      2011-05-27 23:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b36598cf2c62

Merge


Changeset: 472fc37e14a9
Author:    jcoomes
Date:      2011-05-27 23:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/472fc37e14a9

7049385: Bump the HS21 build number to 15
Summary: Update the HS21 build number to 15
Reviewed-by: trims

! make/hotspot_version

Changeset: 1aa57c62d0e4
Author:    jeff
Date:      2011-05-27 15:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1aa57c62d0e4

7045697: JDK7 THIRD PARTY README update
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 63d3fb179034
Author:    lana
Date:      2011-06-02 13:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/63d3fb179034

Merge


Changeset: 9340a27154cb
Author:    kvn
Date:      2011-05-25 21:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9340a27154cb

7048332: Cadd_cmpLTMask doesn't handle 64-bit tmp register properly
Summary: Use ins_encode %{ %} form to encode cadd_cmpLTMask() instruction and remove unused code.
Reviewed-by: never

! src/cpu/x86/vm/x86_64.ad
+ test/compiler/7048332/Test7048332.java

Changeset: ea0da5474c23
Author:    kvn
Date:      2011-05-27 12:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ea0da5474c23

7047069: Array can dynamically change size when assigned to an object field
Summary: Fix initialization of a newly-allocated array with arraycopy
Reviewed-by: never

! src/share/vm/opto/library_call.cpp
+ test/compiler/7047069/Test7047069.java

Changeset: 88559690c95a
Author:    never
Date:      2011-05-26 14:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/88559690c95a

7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly
Reviewed-by: kvn, jrose

! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp

Changeset: 442ef93966a9
Author:    iveresov
Date:      2011-05-26 13:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/442ef93966a9

7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub
Summary: Save and restore the argument registers around the call to checkcast_arraycopy
Reviewed-by: never, roland

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 3f7a95be91ef
Author:    iveresov
Date:      2011-06-01 12:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3f7a95be91ef

Merge


Changeset: 7c907a50c1bb
Author:    iveresov
Date:      2011-06-01 14:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7c907a50c1bb

Merge


Changeset: f88fb2fa90cf
Author:    kvn
Date:      2011-05-31 10:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f88fb2fa90cf

6956668: misbehavior of XOR operator (^) with int
Summary: optimize cmp_ne(xor(X,1),0) to cmp_eq(X,0) only for boolean values X.
Reviewed-by: never

! src/share/vm/opto/subnode.cpp
+ test/compiler/6956668/Test6956668.java

Changeset: ba550512d3b2
Author:    jrose
Date:      2011-06-01 23:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ba550512d3b2

7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError
Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException.
Reviewed-by: never

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: c76d5f44a3fe
Author:    jrose
Date:      2011-06-01 23:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c76d5f44a3fe

7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM
Summary: change the default setting of the flag AllowInvokeGeneric to false
Reviewed-by: never

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

Changeset: deaa3ce90583
Author:    coleenp
Date:      2011-06-02 14:17 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/deaa3ce90583

7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63
Summary: Removed extra change from another bug fix that caused this regression
Reviewed-by: phh, dcubed, kvn, kamg, never

! src/share/vm/oops/methodOop.cpp

Changeset: e5ae807761b8
Author:    trims
Date:      2011-06-03 17:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e5ae807761b8

Added tag hs21-b14 for changeset 62f39d40ebf1

! .hgtags

Changeset: 82a81d5c5700
Author:    trims
Date:      2011-06-03 20:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/82a81d5c5700

Merge


Changeset: 48ceeec759b6
Author:    schien
Date:      2011-06-07 14:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/48ceeec759b6

Added tag jdk7-b145 for changeset 82a81d5c5700

! .hgtags

Changeset: 12537a93a848
Author:    asaha
Date:      2011-04-08 21:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12537a93a848

Merge


Changeset: 540930dc854d
Author:    kamg
Date:      2011-04-12 16:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/540930dc854d

7020373: JSR rewriting can overflow memory address size variables
Summary: Abort if incoming classfile's parameters would cause overflows
Reviewed-by: coleenp, dcubed, never

! src/share/vm/oops/generateOopMap.cpp
+ test/runtime/7020373/Test7020373.sh
+ test/runtime/7020373/testcase.jar

Changeset: f0914807c671
Author:    asaha
Date:      2011-04-20 07:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f0914807c671

Merge


Changeset: bad27cd3f646
Author:    asaha
Date:      2011-04-21 08:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bad27cd3f646

Merge


Changeset: 5e00ed79c8bb
Author:    asaha
Date:      2011-04-21 16:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5e00ed79c8bb

Merge


Changeset: c97b08c7d72a
Author:    asaha
Date:      2011-04-21 22:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c97b08c7d72a

Merge


Changeset: 5def270bc147
Author:    zgu
Date:      2011-04-15 09:34 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5def270bc147

7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls
Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls.
Reviewed-by: acorn, dcubed, ohair, alanb

! make/windows/makefiles/compile.make
! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/jvm_windows.h
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.hpp

Changeset: 089aee76df10
Author:    asaha
Date:      2011-05-04 16:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/089aee76df10

Merge

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

Changeset: ba2db55ddf8b
Author:    asaha
Date:      2011-05-05 22:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ba2db55ddf8b

Merge

- make/linux/makefiles/cscope.make
- make/solaris/makefiles/cscope.make

Changeset: 66c17ec20ee2
Author:    asaha
Date:      2011-05-06 14:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/66c17ec20ee2

Merge


Changeset: 7c948af3e651
Author:    asaha
Date:      2011-05-24 11:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7c948af3e651

Merge

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

Changeset: ec7055a259a6
Author:    asaha
Date:      2011-05-26 17:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ec7055a259a6

Merge


Changeset: 8d5208b557b3
Author:    asaha
Date:      2011-05-26 21:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8d5208b557b3

Merge


Changeset: 7bf54248da9f
Author:    asaha
Date:      2011-06-06 10:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7bf54248da9f

Merge


Changeset: a983caeb2b3e
Author:    asaha
Date:      2011-06-03 07:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a983caeb2b3e

Merge


Changeset: 0e9653efc6ea
Author:    asaha
Date:      2011-06-06 10:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0e9653efc6ea

Merge


Changeset: a884a8b0ec6d
Author:    asaha
Date:      2011-06-15 14:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a884a8b0ec6d

7055247: Ignore test of # 7020373
Reviewed-by: dcubed

! test/runtime/7020373/Test7020373.sh

Changeset: 9d7c66d9a203
Author:    lana
Date:      2011-06-15 16:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9d7c66d9a203

Merge


Changeset: f56542cb325a
Author:    never
Date:      2011-06-02 13:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f56542cb325a

7050554: JSR 292 - need optimization for selectAlternative
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciCallProfile.hpp
! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp

Changeset: f7d55ea6ee56
Author:    never
Date:      2011-06-03 22:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f7d55ea6ee56

7045514: SPARC assembly code for JSR 292 ricochet frames
Reviewed-by: kvn, jrose

! 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.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
+ src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/sparc/vm/registerMap_sparc.hpp
! src/cpu/sparc/vm/runtime_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/stubRoutines_sparc.hpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/cpu/x86/vm/runtime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 293f68bda347
Author:    kvn
Date:      2011-06-04 10:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/293f68bda347

7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity
Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already.
Reviewed-by: iveresov, never

! src/share/vm/opto/escape.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp

Changeset: 14d3cdeabc9f
Author:    trims
Date:      2011-06-07 16:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/14d3cdeabc9f

Added tag hs21-b15 for changeset 82a81d5c5700

! .hgtags

Changeset: 67c0f5f5deac
Author:    trims
Date:      2011-06-07 16:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/67c0f5f5deac

Merge


Changeset: 07c2e7ffd1fc
Author:    jrose
Date:      2011-06-08 17:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/07c2e7ffd1fc

7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp
Reviewed-by: never, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/code/pcDesc.cpp

Changeset: 15e7628f9e92
Author:    trims
Date:      2011-06-16 19:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/15e7628f9e92

Merge


Changeset: fc043ce2136c
Author:    trims
Date:      2011-06-16 19:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fc043ce2136c

7055788: Bump the HS21 build number to 16
Summary: Update the HS21 build number to 16
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: a9b8b43b115f
Author:    never
Date:      2011-06-14 14:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a9b8b43b115f

7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters
Reviewed-by: twisti, kvn, jrose

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubCodeGenerator.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp

Changeset: 3275a6560cf7
Author:    twisti
Date:      2011-06-14 12:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3275a6560cf7

7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops
Reviewed-by: iveresov, never

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

Changeset: 38fa55e5e792
Author:    never
Date:      2011-06-16 13:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/38fa55e5e792

7055355: JSR 292: crash while throwing WrongMethodTypeException
Reviewed-by: jrose, twisti, bdelsart

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.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/zero/vm/cppInterpreter_zero.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp

Changeset: 72701f797a7c
Author:    schien
Date:      2011-06-20 16:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/72701f797a7c

Added tag jdk7-b146 for changeset 38fa55e5e792

! .hgtags

Changeset: f6ba9007b2c6
Author:    jeff
Date:      2011-06-22 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f6ba9007b2c6

7057046: Add embedded license to THIRD PARTY README
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 5bb91b0db2c9
Author:    lana
Date:      2011-06-22 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5bb91b0db2c9

Merge


Changeset: 49d1ee0f1f0c
Author:    trims
Date:      2011-06-21 02:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/49d1ee0f1f0c

Added tag hs21-b16 for changeset 38fa55e5e792

! .hgtags

Changeset: 782e2bb60c41
Author:    kvn
Date:      2011-06-20 16:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/782e2bb60c41

7052494: Eclipse test fails on JDK 7 b142
Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit.
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
+ test/compiler/7052494/Test7052494.java

Changeset: a3081a3a2b54
Author:    never
Date:      2011-06-21 09:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a3081a3a2b54

7056380: VM crashes with SIGSEGV in compiled code
Summary: code was using andq reg, imm instead of addq addr, imm
Reviewed-by: kvn, jrose, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86_64.ad

Changeset: 393e144bb99b
Author:    never
Date:      2011-06-22 14:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/393e144bb99b

7057587: JSR 292 - crash with jruby in test/test_respond_to.rb
Summary: don't skip receiver when GC'ing compiled invokedynamic callsites
Reviewed-by: twisti, kvn, jrose

! src/share/vm/code/nmethod.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/parse.hpp

Changeset: b3a485ccfe86
Author:    trims
Date:      2011-06-23 22:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b3a485ccfe86

Merge


Changeset: e9b51b4bdcc7
Author:    trims
Date:      2011-06-23 22:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e9b51b4bdcc7

7057556: Bump the HS21 build number to 17
Summary: Update the HS21 build number to 17
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 81d815b05abb
Author:    jrose
Date:      2011-06-23 17:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/81d815b05abb

7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path
Reviewed-by: never

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciSignature.cpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/oops/cpCacheOop.cpp
! src/share/vm/oops/cpCacheOop.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: 684b3ad7bfbc
Author:    schien
Date:      2011-06-27 13:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/684b3ad7bfbc

Added tag jdk7-b147 for changeset 81d815b05abb

! .hgtags

Changeset: 9b0ca45cd756
Author:    trims
Date:      2011-06-28 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9b0ca45cd756

Added tag hs21-b17 for changeset 81d815b05abb

! .hgtags

Changeset: 790b18399cd4
Author:    schien
Date:      2011-07-21 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/790b18399cd4

Added tag jdk7u2-b01 for changeset 9b0ca45cd756

! .hgtags

Changeset: 303a4d63b484
Author:    jcoomes
Date:      2011-08-23 21:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/303a4d63b484

7082689: allow duplicate bug ids in jdk7u repos
Reviewed-by: johnc

! .jcheck/conf

Changeset: 8580b4f22e29
Author:    jcoomes
Date:      2011-08-23 21:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8580b4f22e29

Merge

! .jcheck/conf
- agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java
- agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java
! make/hotspot_version
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/os/windows/vm/os_windows.cpp
! src/share/tools/hsdis/README
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/prims/methodHandleWalk.cpp

Changeset: 2c820a7d4f30
Author:    schien
Date:      2011-08-30 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2c820a7d4f30

Added tag jdk7u2-b04 for changeset 8580b4f22e29

! .hgtags

Changeset: e012eb9e136d
Author:    schien
Date:      2011-08-31 15:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e012eb9e136d

Added tag jdk7u2-b05 for changeset 2c820a7d4f30

! .hgtags

Changeset: 45485117e6b9
Author:    jcoomes
Date:      2011-09-06 21:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/45485117e6b9

Merge

! .hgtags
! make/hotspot_version

Changeset: 43252bd4c09d
Author:    jcoomes
Date:      2011-09-06 21:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/43252bd4c09d

Merge

! .hgtags

Changeset: 8bab8fb7adb0
Author:    schien
Date:      2011-09-08 16:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8bab8fb7adb0

Added tag jdk7u2-b06 for changeset 43252bd4c09d

! .hgtags

Changeset: 299ef5b2915d
Author:    schien
Date:      2011-09-14 13:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/299ef5b2915d

Added tag jdk7u2-b07 for changeset 8bab8fb7adb0

! .hgtags

Changeset: 8035e71ac3f6
Author:    jcoomes
Date:      2011-09-19 13:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8035e71ac3f6

Merge

! .hgtags
- agent/src/os/solaris/dbx/Makefile
- agent/src/os/solaris/dbx/README
- agent/src/os/solaris/dbx/README-commands.txt
- agent/src/os/solaris/dbx/helloWorld.cpp
- agent/src/os/solaris/dbx/proc_service_2.h
- agent/src/os/solaris/dbx/shell_imp.h
- agent/src/os/solaris/dbx/svc_agent_dbx.cpp
- agent/src/os/solaris/dbx/svc_agent_dbx.hpp
- agent/src/os/win32/BasicList.hpp
- agent/src/os/win32/Buffer.cpp
- agent/src/os/win32/Buffer.hpp
- agent/src/os/win32/Dispatcher.cpp
- agent/src/os/win32/Dispatcher.hpp
- agent/src/os/win32/Handler.hpp
- agent/src/os/win32/IOBuf.cpp
- agent/src/os/win32/IOBuf.hpp
- agent/src/os/win32/LockableList.hpp
- agent/src/os/win32/Makefile
- agent/src/os/win32/Message.hpp
- agent/src/os/win32/Monitor.cpp
- agent/src/os/win32/Monitor.hpp
- agent/src/os/win32/README-commands.txt
- agent/src/os/win32/README.txt
- agent/src/os/win32/Reaper.cpp
- agent/src/os/win32/Reaper.hpp
- agent/src/os/win32/SwDbgSrv.cpp
- agent/src/os/win32/SwDbgSrv.dsp
- agent/src/os/win32/SwDbgSrv.dsw
- agent/src/os/win32/SwDbgSub.cpp
- agent/src/os/win32/SwDbgSub.dsp
- agent/src/os/win32/initWinsock.cpp
- agent/src/os/win32/initWinsock.hpp
- agent/src/os/win32/ioUtils.cpp
- agent/src/os/win32/ioUtils.hpp
- agent/src/os/win32/isNT4.cpp
- agent/src/os/win32/isNT4.hpp
- agent/src/os/win32/libInfo.cpp
- agent/src/os/win32/libInfo.hpp
- agent/src/os/win32/nt4internals.cpp
- agent/src/os/win32/nt4internals.hpp
- agent/src/os/win32/ports.h
- agent/src/os/win32/procList.cpp
- agent/src/os/win32/procList.hpp
- agent/src/os/win32/serverLists.cpp
- agent/src/os/win32/serverLists.hpp
- agent/src/os/win32/toolHelp.cpp
- agent/src/os/win32/toolHelp.hpp
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java
! make/hotspot_version
- make/solaris/makefiles/mapfile-vers-nonproduct
! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/methodHandleWalk.cpp
- src/share/vm/runtime/reflectionCompat.hpp

Changeset: 17a87e00a541
Author:    schien
Date:      2011-09-22 06:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/17a87e00a541

Added tag jdk7u2-b08 for changeset 8035e71ac3f6

! .hgtags

Changeset: 2c37082ade92
Author:    cl
Date:      2011-10-25 13:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2c37082ade92

Added tag jdk7u2-b10 for changeset 17a87e00a541

! .hgtags

Changeset: 92be6a664a86
Author:    jcoomes
Date:      2011-10-26 12:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/92be6a664a86

7105275: wrong tag added to jdk7u master repos
Reviewed-by: asaha

! .hgtags

Changeset: 7e508fbcb950
Author:    jcoomes
Date:      2011-10-27 12:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7e508fbcb950

Merge

! .hgtags
! make/hotspot_version
- make/templates/bsd-header
! src/cpu/x86/vm/vm_version_x86.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/methodHandleWalk.cpp

Changeset: b6d9d5bbea50
Author:    katleman
Date:      2011-11-16 16:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b6d9d5bbea50

Added tag jdk7u4-b01 for changeset 7e508fbcb950

! .hgtags

Changeset: 35aadd2e739b
Author:    jcoomes
Date:      2011-11-18 19:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/35aadd2e739b

Merge

! .hgtags
! make/hotspot_version
- src/share/vm/precompiled.hpp

Changeset: 278a1c1706f0
Author:    katleman
Date:      2011-12-09 17:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/278a1c1706f0

Added tag jdk7u4-b03 for changeset 35aadd2e739b

! .hgtags

Changeset: 21dbf8183550
Author:    katleman
Date:      2011-12-15 09:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/21dbf8183550

Added tag jdk7u4-b04 for changeset 278a1c1706f0

! .hgtags

Changeset: a33d99dd8b24
Author:    katleman
Date:      2011-12-14 17:30 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a33d99dd8b24

Added tag jdk7u4-b02 for changeset 35aadd2e739b

! .hgtags

Changeset: 7bb156f60fdc
Author:    katleman
Date:      2011-12-15 12:57 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7bb156f60fdc

Merge

! .hgtags

Changeset: 1647361df7ba
Author:    amurillo
Date:      2011-12-16 15:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1647361df7ba

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp

Changeset: de5af98a6fac
Author:    cl
Date:      2011-12-21 20:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/de5af98a6fac

Added tag jdk7u4-b05 for changeset 1647361df7ba

! .hgtags

Changeset: b09b616c066f
Author:    amurillo
Date:      2011-12-23 15:39 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b09b616c066f

Merge

! .hgtags
! make/hotspot_version
! src/os/windows/vm/os_windows.cpp

Changeset: 93189257531e
Author:    katleman
Date:      2011-12-28 15:41 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/93189257531e

Added tag jdk7u4-b06 for changeset b09b616c066f

! .hgtags

Changeset: 3804879a5ea0
Author:    amurillo
Date:      2012-01-14 01:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3804879a5ea0

Merge

! .hgtags
! make/hotspot_version
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp

Changeset: 899ddc704d9f
Author:    katleman
Date:      2012-01-19 09:35 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/899ddc704d9f

Added tag jdk7u4-b07 for changeset 3804879a5ea0

! .hgtags

Changeset: 9f7d76c6b0a8
Author:    katleman
Date:      2012-01-23 10:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9f7d76c6b0a8

Added tag jdk7u4-b08 for changeset 899ddc704d9f

! .hgtags

Changeset: c5695e7d2e4f
Author:    amurillo
Date:      2012-01-24 14:50 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c5695e7d2e4f

Merge

! .hgtags
! make/hotspot_version
- src/os/bsd/vm/decoder_bsd.cpp
! src/os/windows/vm/os_windows.cpp

Changeset: f926bdee9aba
Author:    katleman
Date:      2012-01-27 08:49 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f926bdee9aba

Added tag jdk7u4-b09 for changeset c5695e7d2e4f

! .hgtags

Changeset: 305636960fa4
Author:    amurillo
Date:      2012-01-27 15:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/305636960fa4

Merge

! .hgtags
! make/hotspot_version
! src/os/windows/vm/os_windows.cpp

Changeset: 6b53e4c71c8a
Author:    katleman
Date:      2012-02-03 01:39 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6b53e4c71c8a

Added tag jdk7u4-b10 for changeset 305636960fa4

! .hgtags

Changeset: acb171a8d7d6
Author:    amurillo
Date:      2012-02-06 12:30 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/acb171a8d7d6

Merge

! .hgtags
! make/hotspot_version
! src/os/windows/vm/os_windows.cpp

Changeset: c0d7fd785f0b
Author:    katleman
Date:      2012-02-09 12:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c0d7fd785f0b

Added tag jdk7u4-b11 for changeset acb171a8d7d6

! .hgtags

Changeset: 87b4042571ef
Author:    amurillo
Date:      2012-02-10 12:03 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/87b4042571ef

Merge

! .hgtags
! make/hotspot_version

Changeset: 963d912a0409
Author:    katleman
Date:      2012-02-16 13:01 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/963d912a0409

Added tag jdk7u4-b12 for changeset 87b4042571ef

! .hgtags

Changeset: efb5f2662c96
Author:    amurillo
Date:      2012-02-20 23:21 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/efb5f2662c96

Merge

! .hgtags
! make/hotspot_version
! src/cpu/x86/vm/vm_version_x86.hpp

Changeset: 82e719a2e641
Author:    katleman
Date:      2012-02-23 15:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/82e719a2e641

Added tag jdk7u4-b13 for changeset efb5f2662c96

! .hgtags

Changeset: 6b71938ee832
Author:    katleman
Date:      2012-03-13 12:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6b71938ee832

Added tag jdk7u6-b01 for changeset 82e719a2e641

! .hgtags

Changeset: f1bccf74b888
Author:    katleman
Date:      2012-03-19 23:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f1bccf74b888

Added tag jdk7u6-b02 for changeset 6b71938ee832

! .hgtags

Changeset: 1c483d994a78
Author:    katleman
Date:      2012-03-01 13:44 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1c483d994a78

Added tag jdk7u4-b14 for changeset 82e719a2e641

! .hgtags

Changeset: 3894b5f634a8
Author:    katleman
Date:      2012-03-08 11:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3894b5f634a8

Added tag jdk7u4-b15 for changeset 1c483d994a78

! .hgtags

Changeset: cf8928e22f20
Author:    amurillo
Date:      2012-02-28 15:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cf8928e22f20

7148663: new hotspot build - hs23-b17
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 3322dd7f0a4d
Author:    dsamersoff
Date:      2012-02-29 15:59 +0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3322dd7f0a4d

7110104: It should be possible to stop and start JMX Agent at runtime
Summary: Added a capability to start and stop JMX Agent by jcmd
Reviewed-by: acorn, mchung

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp

Changeset: eac434b01c4c
Author:    kvn
Date:      2012-02-21 11:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/eac434b01c4c

7146442: assert(false) failed: bad AD file
Summary: Take into account only stores captured by Initialize node. Added missing check for Top input in value() methods.
Reviewed-by: never

! src/share/vm/opto/connode.cpp
! src/share/vm/opto/escape.cpp

Changeset: ad0b499ddb18
Author:    never
Date:      2012-02-28 10:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ad0b499ddb18

7145024: Crashes in ucrypto related to C2
Reviewed-by: kvn

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

Changeset: 34a4f7687460
Author:    never
Date:      2012-03-01 15:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/34a4f7687460

7150051: incorrect oopmap in critical native
Reviewed-by: kvn, twisti

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

Changeset: 66eb62861bb0
Author:    amurillo
Date:      2012-03-10 00:38 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/66eb62861bb0

Added tag hs23-b17 for changeset 34a4f7687460

! .hgtags

Changeset: c6a96f7a781d
Author:    amurillo
Date:      2012-03-10 00:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c6a96f7a781d

Merge

! .hgtags
! make/hotspot_version

Changeset: 376549fed156
Author:    katleman
Date:      2012-03-16 07:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/376549fed156

Added tag jdk7u4-b16 for changeset c6a96f7a781d

! .hgtags

Changeset: bca9e76ea254
Author:    asaha
Date:      2012-03-20 10:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bca9e76ea254

Merge

! .hgtags

Changeset: b82c43fba5c0
Author:    cl
Date:      2012-03-27 10:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b82c43fba5c0

Added tag jdk7u6-b03 for changeset bca9e76ea254

! .hgtags

Changeset: be0853fa2583
Author:    cl
Date:      2012-04-02 14:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/be0853fa2583

Added tag jdk7u6-b04 for changeset b82c43fba5c0

! .hgtags

Changeset: 16d263c59845
Author:    amurillo
Date:      2012-03-10 00:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/16d263c59845

7150326: new hotspot build - hs23-b18
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1425699d00c2
Author:    never
Date:      2012-03-06 16:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1425699d00c2

7150390: JFR test crashed on assert(_jni_lock_count == count) failed: must be equal
Reviewed-by: dholmes, minqi, kvn, coleenp

! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: 418bcab91d2c
Author:    jcoomes
Date:      2012-03-15 14:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/418bcab91d2c

7150454: add release jdk7u4 to jprt.properties
Reviewed-by: ohair, never

! make/jprt.properties

Changeset: a670de856959
Author:    amurillo
Date:      2012-03-16 17:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a670de856959

Added tag hs23-b18 for changeset 418bcab91d2c

! .hgtags

Changeset: e266ffd6a7d7
Author:    amurillo
Date:      2012-03-16 17:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e266ffd6a7d7

Merge

! .hgtags
! make/hotspot_version

Changeset: cc347bb8cf1b
Author:    katleman
Date:      2012-03-22 14:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cc347bb8cf1b

Added tag jdk7u4-b17 for changeset e266ffd6a7d7

! .hgtags

Changeset: cd3d4ec354fd
Author:    jcoomes
Date:      2011-09-20 22:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cd3d4ec354fd

7093108: Bump the hs22 build number to 07
Reviewed-by: johnc
Contributed-by: alejandro.murillo at oracle.com

! make/hotspot_version

Changeset: f79fb21f3cad
Author:    jcoomes
Date:      2011-09-20 22:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f79fb21f3cad

Added tag hs22-b07 for changeset cd3d4ec354fd

! .hgtags

Changeset: b93bc193d73b
Author:    jcoomes
Date:      2011-09-23 11:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b93bc193d73b

Merge

! .hgtags
! make/hotspot_version

Changeset: c407af9f1f59
Author:    katleman
Date:      2011-09-26 12:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c407af9f1f59

Added tag jdk7u2-b09 for changeset b93bc193d73b

! .hgtags

Changeset: 8d4cd133d6a8
Author:    tonyp
Date:      2011-09-20 09:59 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8d4cd133d6a8

7059019: G1: add G1 support to the SA
Summary: Extend the SA to recognize the G1CollectedHeap and implement any code that's needed by our serviceability tools (jmap, jinfo, jstack, etc.) that depend on the SA.
Reviewed-by: never, poonam, johnc

! agent/make/Makefile
+ agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java
+ agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegion.java
+ agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java
! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! make/sa.files
! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
+ src/share/vm/gc_implementation/g1/vmStructs_g1.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 66db4a2fc13c
Author:    johnc
Date:      2011-09-20 15:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/66db4a2fc13c

7092412: G1: Some roots not marked during an initial mark that gets an evacuation failure
Summary: As a result of the changes for 7080389, an evacuation failure during an initial mark pause may result in some root objects not being marked. Pass whether the caller is a root scanning closure into the evacuation failure handling code so that the thread that successfully forwards an object to itself also marks the object.
Reviewed-by: ysr, brutisso, tonyp

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

Changeset: 2115638addd2
Author:    tonyp
Date:      2011-09-21 01:27 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2115638addd2

7045232: G1: pool names are inconsistent with other collectors (don't have 'Space')
Summary: Make sure the eden and survivor pools have "Space" in their name.
Reviewed-by: jmasa, ysr

! src/share/vm/services/g1MemoryPool.cpp

Changeset: ce597819d5c6
Author:    johnc
Date:      2011-09-21 10:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ce597819d5c6

7068215: G1: Print reference processing time during remark
Summary: Displays the elapsed time taken to perform reference processing during remark as part of the PrintGCDetails output.
Reviewed-by: ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: ac196b091535
Author:    tonyp
Date:      2011-09-21 13:36 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ac196b091535

7091032: G1: assert failure when NewRatio is used
Summary: The desired min / max heap sizes are miscalculated at initialization when NewRatio is used. The changeset also includes an additional small change to turn a print statement into a warning.
Reviewed-by: johnc, jmasa, ysr, brutisso

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp

Changeset: e804fc7a831e
Author:    johnc
Date:      2011-09-21 15:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e804fc7a831e

7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header output
Summary: Cast HeapRegion::GrainBytes to size_t in output statement.
Reviewed-by: ysr, brutisso, pbk, tonyp

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: c20e006ee26a
Author:    tonyp
Date:      2011-09-22 07:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c20e006ee26a

7092238: G1: Uninitialized field gc_efficiency in G1PrintRegionLivenessInfo output
Reviewed-by: jcoomes, johnc

! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: d320dd70ca40
Author:    johnc
Date:      2011-09-22 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d320dd70ca40

6484982: G1: process references during evacuation pauses
Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate.
Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/satbQueue.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/runtime/thread.cpp

Changeset: 39c57c097027
Author:    tonyp
Date:      2011-09-23 16:07 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/39c57c097027

7075646: G1: fix inconsistencies in the monitoring data
Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat.
Reviewed-by: jmasa, brutisso, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/shared/generationCounters.cpp
! src/share/vm/gc_implementation/shared/generationCounters.hpp
! src/share/vm/services/g1MemoryPool.cpp
! src/share/vm/services/g1MemoryPool.hpp

Changeset: 9a9821a0bc8b
Author:    johnc
Date:      2011-09-28 10:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9a9821a0bc8b

7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835
Summary: Some objects may not be marked in the event of an evacuation failure in a partially young GC, during a marking cycle. Avoid this situation by not allowing partially young GCs during a marking cycle.
Reviewed-by: tonyp, ysr, brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp

Changeset: 7afaeffa5d9b
Author:    johnc
Date:      2011-10-03 12:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7afaeffa5d9b

7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054
Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning.
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: aade124d1b1d
Author:    tonyp
Date:      2011-10-03 19:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aade124d1b1d

7097048: G1: extend the G1 SA changes to print per-heap space information
Reviewed-by: brutisso, johnc

! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java
+ agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp
! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp

Changeset: 953ffc48897d
Author:    never
Date:      2011-09-20 23:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/953ffc48897d

7092236: java/util/EnumSet/EnumSetBash.java fails
Reviewed-by: kvn, twisti, jrose

! src/share/vm/ci/ciEnv.cpp

Changeset: 34d69affce86
Author:    never
Date:      2011-09-29 09:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/34d69affce86

7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137"
Reviewed-by: kvn

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
+ agent/src/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 876f4a66bd71
Author:    bdelsart
Date:      2011-10-07 13:28 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/876f4a66bd71

7096366: PPC: corruption of floating-point values with DeoptimizeALot
Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms
Reviewed-by: roland, dholmes

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

Changeset: c2ef8b5cd1f3
Author:    never
Date:      2011-10-13 14:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c2ef8b5cd1f3

7100165: JSR 292: leftover printing code in methodHandleWalk.cpp
Reviewed-by: kvn, twisti

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

Changeset: 623aec2a90f7
Author:    jcoomes
Date:      2011-10-14 12:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/623aec2a90f7

7101102: Bump the hs22 build number to 08
Reviewed-by: johnc
Contributed-by: alejandro.murillo at oracle.com

! make/hotspot_version

Changeset: d38fde25cf49
Author:    jcoomes
Date:      2011-10-14 12:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d38fde25cf49

Added tag hs22-b08 for changeset 623aec2a90f7

! .hgtags

Changeset: 482e282037d7
Author:    jcoomes
Date:      2011-10-18 17:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/482e282037d7

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/prims/methodHandleWalk.cpp

Changeset: 0418640475c3
Author:    katleman
Date:      2011-10-27 12:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0418640475c3

Added tag jdk7u2-b11 for changeset 482e282037d7

! .hgtags

Changeset: 3e986ec5c123
Author:    asaha
Date:      2011-10-31 22:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3e986ec5c123

7107063: Fork hs22.1 hsx from hs22.0 for 7u3 and reinitialize build number
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 68d4d1b6829a
Author:    jeff
Date:      2011-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/68d4d1b6829a

7102337: Third Party License Readme updates for 7u2
Reviewed-by: lana, ohair

! THIRD_PARTY_README

Changeset: b07e591a1675
Author:    lana
Date:      2011-11-04 11:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b07e591a1675

Merge


Changeset: 714bf7aefe10
Author:    kvn
Date:      2011-10-14 10:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/714bf7aefe10

7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc
Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic.
Reviewed-by: never, twisti

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/7100757/Test7100757.java

Changeset: c8abdaa56b47
Author:    jcoomes
Date:      2011-11-08 11:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c8abdaa56b47

7108550: Bump the hs22 build number to 09
Reviewed-by: johnc
Contributed-by: alejandro.murillo at oracle.com

! make/hotspot_version

Changeset: 12a4ef429155
Author:    jcoomes
Date:      2011-11-08 11:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12a4ef429155

Added tag hs22-b09 for changeset c8abdaa56b47

! .hgtags

Changeset: 4061b13e3e6b
Author:    jcoomes
Date:      2011-11-08 13:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4061b13e3e6b

Merge

! .hgtags
! make/hotspot_version

Changeset: a67789172db1
Author:    katleman
Date:      2011-11-10 11:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a67789172db1

Added tag jdk7u2-b12 for changeset 4061b13e3e6b

! .hgtags

Changeset: 742a2251c87b
Author:    kvn
Date:      2011-11-10 20:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/742a2251c87b

7110586: C2 generates incorrect results
Summary: Exact limit of empty loop calculated incorrectly.
Reviewed-by: iveresov, never

! src/share/vm/opto/loopnode.cpp
+ test/compiler/7110586/Test7110586.java

Changeset: 0544a9618b87
Author:    poonam
Date:      2011-11-16 16:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0544a9618b87

7110428: Crash during HeapDump operation
Reviewed-by: ysr, dholmes

! src/share/vm/services/heapDumper.cpp

Changeset: 3ba0bb2e7c8d
Author:    jcoomes
Date:      2011-11-16 17:44 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3ba0bb2e7c8d

7112766: Bump the hs22 build number to 10
Reviewed-by: johnc
Contributed-by: alejandro.murillo at oracle.com

! make/hotspot_version

Changeset: c6cd7638991b
Author:    jcoomes
Date:      2011-11-16 17:44 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c6cd7638991b

Added tag hs22-b10 for changeset 3ba0bb2e7c8d

! .hgtags

Changeset: f17fe2f4b6aa
Author:    jcoomes
Date:      2011-11-16 17:50 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f17fe2f4b6aa

Merge

! .hgtags
! make/hotspot_version

Changeset: 0744602f85c6
Author:    katleman
Date:      2011-11-17 22:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0744602f85c6

Added tag jdk7u2-b13 for changeset f17fe2f4b6aa

! .hgtags

Changeset: c7bc239126d3
Author:    asaha
Date:      2011-11-18 12:57 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c7bc239126d3

Merge

! make/hotspot_version

Changeset: b23c8435518c
Author:    asaha
Date:      2011-11-29 10:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b23c8435518c

7116462: Bump the hs21.1 build number to 02
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: df4652fd1ae5
Author:    asaha
Date:      2011-11-29 11:13 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/df4652fd1ae5

7113740: hotspot_version file has wrong JDK_MINOR_VER
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 7333a200d09e
Author:    asaha
Date:      2011-11-30 13:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7333a200d09e

Merge

! make/hotspot_version

Changeset: a40d238623e5
Author:    asaha
Date:      2011-11-30 15:32 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a40d238623e5

Merge


Changeset: e20578af5890
Author:    cl
Date:      2011-12-12 22:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e20578af5890

Added tag jdk7u3-b02 for changeset a40d238623e5

! .hgtags

Changeset: 6259c6d3bbb7
Author:    cl
Date:      2011-12-12 23:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6259c6d3bbb7

Added tag jdk7u2-b21 for changeset 0744602f85c6

! .hgtags

Changeset: 6986bfb4c82e
Author:    asaha
Date:      2012-01-10 13:12 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6986bfb4c82e

Merge

! .hgtags

Changeset: 8e6375b46717
Author:    katleman
Date:      2012-01-12 14:23 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8e6375b46717

Added tag jdk7u3-b03 for changeset 6986bfb4c82e

! .hgtags

Changeset: 366e6ba09c99
Author:    katleman
Date:      2012-01-23 09:47 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/366e6ba09c99

Added tag jdk7u3-b04 for changeset 8e6375b46717

! .hgtags

Changeset: 4c62237db349
Author:    katleman
Date:      2012-01-27 12:03 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4c62237db349

Added tag jdk7u3-b20 for changeset 366e6ba09c99

! .hgtags

Changeset: 6067412a3452
Author:    katleman
Date:      2012-02-07 12:26 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6067412a3452

Added tag jdk7u3-b05 for changeset 4c62237db349

! .hgtags

Changeset: ce271da83629
Author:    asaha
Date:      2012-03-23 09:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ce271da83629

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/opto/loopnode.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 8f31e6a9b691
Author:    amurillo
Date:      2012-03-16 17:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8f31e6a9b691

7152784: new hotspot build - hs23-b19
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b7175879a006
Author:    brutisso
Date:      2012-03-13 21:12 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b7175879a006

7152954: G1: Native memory leak during full GCs
Summary: Add destructor to TruncatedSeq and call delete when necessary
Reviewed-by: johnc, tonyp

! src/share/vm/gc_implementation/g1/survRateGroup.cpp
! src/share/vm/utilities/numberSeq.cpp
! src/share/vm/utilities/numberSeq.hpp

Changeset: a5f2ffa62a17
Author:    sspitsyn
Date:      2012-03-17 02:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a5f2ffa62a17

7123170: JCK vm/jvmti/ResourceExhausted/resexh001/resexh00101/ tests fails since 7u4 b02
Summary: The JVMTI ResourceExhausted events must be generated in all places where OOME is thrown
Reviewed-by: acorn, coleenp, dcubed, dholmes, dsamersoff, jwilhelm, tonyp
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/prims/jvmtiExport.hpp

Changeset: 63312751e1e6
Author:    minqi
Date:      2012-03-21 09:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/63312751e1e6

Merge


Changeset: ab565ffd9ec9
Author:    iveresov
Date:      2012-03-21 12:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ab565ffd9ec9

7154333: JVM fails to start if -XX:+AggressiveHeap is set
Summary: Don't set CompilationPolicyChoice with AggressiveHeap
Reviewed-by: never, kvn

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

Changeset: 0ecdb26f147b
Author:    iveresov
Date:      2012-03-21 11:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0ecdb26f147b

Merge


Changeset: 6c1189bed856
Author:    iveresov
Date:      2012-03-21 15:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6c1189bed856

Merge


Changeset: 592be2b070a9
Author:    jcoomes
Date:      2012-03-21 22:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/592be2b070a9

7154724: jdk7u4 test properties missing from jprt.properties
Reviewed-by: brutisso

! make/jprt.properties

Changeset: 74229f694686
Author:    dlong
Date:      2012-02-29 12:58 -0500
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/74229f694686

7142641: -Xshared:on fails on ARM
Summary: map read-only pages MAP_PRIVATE instead of MAP_SHARED
Reviewed-by: dcubed, dholmes
Contributed-by: dean.long at oracle.com

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

Changeset: 0777128def78
Author:    jmelvin
Date:      2012-03-22 17:27 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0777128def78

7144328: Improper commandlines for -XX:+-UnlockCommercialFeatures require proper warning/error messages
Summary: Provide custom error messages for locked commercial feature options which are not first unlocked.
Reviewed-by: dcubed, jcoomes, kamg, dholmes

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

Changeset: b5ab741f2be1
Author:    jcoomes
Date:      2012-03-22 15:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b5ab741f2be1

7155757: make jdk7u4 the default jprt release for hs23
Reviewed-by: kvn, kamg, sspitsyn

! make/jprt.properties

Changeset: ad5eb0a72fb1
Author:    jmelvin
Date:      2012-03-22 23:51 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ad5eb0a72fb1

7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6
Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs.  Also, improve os.name string matching by using contains() method instead of .startsWith().
Reviewed-by: dcubed, phh, ohair, katleman

! agent/src/share/classes/sun/jvm/hotspot/jdi/ConnectorImpl.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java

Changeset: f0a0f737689f
Author:    jcoomes
Date:      2012-03-24 07:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f0a0f737689f

Added tag hs23-b19 for changeset ad5eb0a72fb1

! .hgtags

Changeset: f1b786625e0c
Author:    jcoomes
Date:      2012-03-24 07:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f1b786625e0c

Merge

! .hgtags
! make/hotspot_version

Changeset: 1b1e6060a7fd
Author:    cl
Date:      2012-03-29 15:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1b1e6060a7fd

Added tag jdk7u4-b18 for changeset f1b786625e0c

! .hgtags

Changeset: 43dfede919f5
Author:    asaha
Date:      2012-04-02 09:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/43dfede919f5

Merge

! .hgtags

Changeset: 77b43af50556
Author:    asaha
Date:      2012-04-02 14:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/77b43af50556

Merge

! .hgtags

Changeset: be1d97cdee46
Author:    katleman
Date:      2012-04-16 16:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/be1d97cdee46

Added tag jdk7u6-b05 for changeset 77b43af50556

! .hgtags

Changeset: a5bf59f9ec72
Author:    katleman
Date:      2012-04-18 14:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a5bf59f9ec72

Added tag jdk7u6-b06 for changeset be1d97cdee46

! .hgtags

Changeset: bd649a0a58e2
Author:    jcoomes
Date:      2012-03-24 07:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bd649a0a58e2

7154677: new hotspot build - hs23-b20
Reviewed-by: johnc

! make/hotspot_version

Changeset: f5fba31ac5ce
Author:    dcubed
Date:      2012-03-25 19:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f5fba31ac5ce

Merge


Changeset: de5748cca211
Author:    johnc
Date:      2012-03-12 14:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/de5748cca211

7147724: G1: hang in SurrogateLockerThread::manipulatePLL
Summary: Attempting to initiate a marking cycle when allocating a humongous object can, if a marking cycle is successfully initiated by another thread, result in the allocating thread spinning until the marking cycle is complete. Eliminate a deadlock between the main ConcurrentMarkThread, the SurrogateLocker thread, the VM thread, and a mutator thread waiting on the SecondaryFreeList_lock (while free regions are going to become available) by not manipulating the pending list lock during the prologue and epilogue of the cleanup pause.
Reviewed-by: brutisso, jcoomes, tonyp

! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp

Changeset: c1606f7a714c
Author:    brutisso
Date:      2012-03-23 15:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c1606f7a714c

7103665: HeapWord*ParallelScavengeHeap::failed_mem_allocate(unsigned long,bool)+0x97
Summary: Make sure that MutableNUMASpace::ensure_parsability() only calls CollectedHeap::fill_with_object() with valid sizes and make sure CollectedHeap::filler_array_max_size() returns a value that can be converted to an int without overflow
Reviewed-by: azeemj, jmasa, iveresov

! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp

Changeset: 1db5b993a0d8
Author:    dsamersoff
Date:      2012-03-29 01:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1db5b993a0d8

7118280: The gbyc00102 JCK7 test causes an assert in JVM 7.0 fastdebug mode
Summary: Assert doesn't respect invokedynamic opcode
Reviewed-by: dcubed, phh

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

Changeset: d5ff739e96c7
Author:    dsamersoff
Date:      2012-03-28 14:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d5ff739e96c7

Merge


Changeset: 1834c6835b75
Author:    minqi
Date:      2012-03-29 11:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1834c6835b75

7156960: Incorrect copyright headers in parts of the Serviceability agent
Summary: Errant files added as part of 7088955 fix. The Copyright information now corrected with gpl-header template
Reviewed-by: sla, ohair, mbykov

! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/DataLayout.java
! agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java

Changeset: 726d1dc1b521
Author:    amurillo
Date:      2012-03-30 13:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/726d1dc1b521

Added tag hs23-b20 for changeset 1834c6835b75

! .hgtags

Changeset: a1292d4e0709
Author:    amurillo
Date:      2012-03-30 13:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a1292d4e0709

Merge

! .hgtags
! make/hotspot_version

Changeset: 30e3475c1a45
Author:    katleman
Date:      2012-04-05 15:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/30e3475c1a45

Added tag jdk7u4-b19 for changeset a1292d4e0709

! .hgtags

Changeset: 7c99c217cc89
Author:    amurillo
Date:      2012-03-30 13:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7c99c217cc89

7158135: new hotspot build - hs23-b21
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 34fce1d343b0
Author:    iveresov
Date:      2012-04-07 12:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/34fce1d343b0

7159766: Tiered compilation causes performance regressions
Summary: Disable tiered in 7u4 because of the performance anomalies with Oracle FMW
Reviewed-by: never, kvn

! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp

Changeset: bf81dbf47dec
Author:    jcoomes
Date:      2012-04-10 14:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bf81dbf47dec

Added tag hs23-b21 for changeset 34fce1d343b0

! .hgtags

Changeset: ad6f5eaa165e
Author:    jcoomes
Date:      2012-04-10 16:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ad6f5eaa165e

Merge

! .hgtags
! make/hotspot_version

Changeset: c7c6b00122cf
Author:    katleman
Date:      2012-04-12 14:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c7c6b00122cf

Added tag jdk7u4-b20 for changeset ad6f5eaa165e

! .hgtags

Changeset: dd238f9705f0
Author:    asaha
Date:      2012-04-16 11:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dd238f9705f0

Merge

! .hgtags

Changeset: 515d07d42f87
Author:    asaha
Date:      2012-04-17 11:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/515d07d42f87

Merge

! .hgtags

Changeset: 144f8a1a43cb
Author:    asaha
Date:      2012-04-19 07:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/144f8a1a43cb

Merge

! .hgtags

Changeset: 6b668c1049a8
Author:    katleman
Date:      2012-04-23 15:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6b668c1049a8

Added tag jdk7u6-b07 for changeset 144f8a1a43cb

! .hgtags

Changeset: 94d7a305da4d
Author:    katleman
Date:      2012-05-02 14:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/94d7a305da4d

Added tag jdk7u6-b08 for changeset 6b668c1049a8

! .hgtags

Changeset: 103fc6756e1e
Author:    katleman
Date:      2012-05-10 13:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/103fc6756e1e

Added tag jdk7u6-b09 for changeset 94d7a305da4d

! .hgtags

Changeset: c1d1c84a2124
Author:    amurillo
Date:      2012-05-07 14:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c1d1c84a2124

7167028: new hotspot build - hs23.2-b01
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: adaa2f10c81b
Author:    sla
Date:      2012-02-19 13:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/adaa2f10c81b

7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX
Summary: Change OSThread to use mach thread_t
Reviewed-by: phh, dcubed

! src/cpu/x86/vm/vm_version_x86.cpp
! src/os/bsd/vm/osThread_bsd.cpp
! src/os/bsd/vm/osThread_bsd.hpp
! src/os/bsd/vm/os_bsd.cpp
! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp

Changeset: 8bf0501658ef
Author:    sla
Date:      2012-03-19 20:13 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8bf0501658ef

7152800: All tests using the attach API fail with "well-known file is not secure" on Mac OS X
Summary: Create well-known file with effective group of the current process
Reviewed-by: kamg, dcubed

! src/os/bsd/vm/attachListener_bsd.cpp

Changeset: 0653bc115ff5
Author:    dcubed
Date:      2012-05-08 11:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0653bc115ff5

Merge


Changeset: 690f89a699b1
Author:    dcubed
Date:      2012-05-08 11:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/690f89a699b1

7164344: enabling ZIP_DEBUGINFO_FILES causes unexpected test failures on Solaris and Windows
Summary: Disable FDS by default on Solaris; disable ZIP_DEBUGINFO_FILES by default on Windows.
Reviewed-by: acorn, sspitsyn

! make/solaris/makefiles/defs.make
! make/windows/makefiles/defs.make

Changeset: 28392714005e
Author:    kvn
Date:      2012-05-08 15:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/28392714005e

7167266: missing copyright notes in 3rd party code
Summary: add missing copyright notes to the regression test file.
Reviewed-by: twisti, johnc

! test/compiler/7070134/Stemmer.java

Changeset: 1a9c601a5395
Author:    dholmes
Date:      2012-05-09 00:28 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1a9c601a5395

7167406: (Zero) Fix for InvokeDynamic needed
Reviewed-by: chrisphi, dholmes
Contributed-by: Andrew Dinn <adinn at redhat.com>

! src/cpu/zero/vm/cppInterpreter_zero.cpp

Changeset: 1fcba869fe4a
Author:    nloodin
Date:      2012-05-09 16:24 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1fcba869fe4a

7163117: Agent can't connect to process on Mac OSX
Reviewed-by: dholmes, coleenp, sla, minqi, kvn

! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java

Changeset: b65719ad597b
Author:    amurillo
Date:      2012-05-11 11:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b65719ad597b

Added tag hs23.2-b01 for changeset 1fcba869fe4a

! .hgtags

Changeset: 702b62a5e1a5
Author:    amurillo
Date:      2012-05-11 11:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/702b62a5e1a5

Merge

! .hgtags
! make/hotspot_version
! src/cpu/x86/vm/vm_version_x86.cpp

Changeset: 3be0dd52ccda
Author:    katleman
Date:      2012-05-17 14:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3be0dd52ccda

Added tag jdk7u6-b10 for changeset 702b62a5e1a5

! .hgtags

Changeset: e0b69099f2cf
Author:    amurillo
Date:      2012-05-11 11:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e0b69099f2cf

7168249: new hotspot build - hs23.2-b02
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b7ae1ee1d2e4
Author:    collins
Date:      2012-05-11 11:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b7ae1ee1d2e4

7167625: Adjustments for SE-Embedded build process
Summary: Simple change to the SE-Embedded build rules that should not affect any other OpenJDK users.
Reviewed-by: kvn, dholmes

! make/linux/makefiles/vm.make
! src/share/vm/runtime/arguments.cpp

Changeset: 7eeb0ec83cd7
Author:    amurillo
Date:      2012-05-18 11:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7eeb0ec83cd7

Added tag hs23.2-b02 for changeset b7ae1ee1d2e4

! .hgtags

Changeset: 5921bdc6ce5c
Author:    amurillo
Date:      2012-05-18 11:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5921bdc6ce5c

Merge

! .hgtags
! make/hotspot_version

Changeset: 897d453d26ac
Author:    katleman
Date:      2012-05-24 15:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/897d453d26ac

Added tag jdk7u6-b11 for changeset 5921bdc6ce5c

! .hgtags

Changeset: c7a2af36ee59
Author:    amurillo
Date:      2012-05-18 12:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c7a2af36ee59

7170009: new hotspot build - hs23.2-b03
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 8a074526ffca
Author:    nloodin
Date:      2012-05-10 15:44 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8a074526ffca

7165755: OS Information much longer on linux than other platforms
Reviewed-by: sla, dholmes

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/posix/vm/os_posix.cpp
+ src/os/posix/vm/os_posix.hpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.hpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.hpp
! src/share/vm/runtime/os.hpp

Changeset: 3b1b50b3ad62
Author:    never
Date:      2012-04-02 16:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3b1b50b3ad62

7157141: crash in 64 bit with corrupted oops
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/memory/barrierSet.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: acd6a3802609
Author:    iveresov
Date:      2012-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/acd6a3802609

7160539: JDeveloper crashes on 64-bit Windows
Summary: x64 C1 needs to zero upper 32bits when doing l2i conversion
Reviewed-by: never, kvn

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: ea3152ff2a49
Author:    roland
Date:      2012-05-18 15:50 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ea3152ff2a49

7167254: Crash on OSX in Enumerator.nextElement() with compressed oops
Summary: null checks in "compressed oops with base" mode may trigger a SIGBUS rather than a SIGSEGV.
Reviewed-by: dsamersoff, dcubed, rbackman, kvn

! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp

Changeset: 3facbb14e873
Author:    kvn
Date:      2012-05-14 09:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3facbb14e873

6924259: Remove String.count/String.offset
Summary: Allow a version of String class that doesn't have count and offset fields.
Reviewed-by: never, coleenp

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/dump.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/stringopts.hpp

Changeset: c4b58f8eeeaf
Author:    mikael
Date:      2012-05-15 00:56 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c4b58f8eeeaf

7158457: division by zero in adaptiveweightedaverage
Summary: Add ceiling to AdaptiveWeightedAverage
Reviewed-by: ysr, iveresov

! src/share/vm/gc_implementation/shared/gcUtil.cpp
! src/share/vm/gc_implementation/shared/gcUtil.hpp

Changeset: 3f1e457eda51
Author:    dholmes
Date:      2012-05-23 20:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3f1e457eda51

7170197: Update JPRT default build targets to support embedded builds
Reviewed-by: jcoomes, kvn

! make/jprt.properties

Changeset: e974e1594565
Author:    dholmes
Date:      2012-05-25 05:12 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e974e1594565

Merge


Changeset: 365d216f0666
Author:    amurillo
Date:      2012-05-25 13:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/365d216f0666

Added tag hs23.2-b03 for changeset e974e1594565

! .hgtags

Changeset: f08a3a0e60c3
Author:    amurillo
Date:      2012-05-25 13:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f08a3a0e60c3

Merge

! .hgtags
! make/hotspot_version
! src/os/windows/vm/os_windows.cpp

Changeset: 36f64ab3c9ca
Author:    katleman
Date:      2012-05-31 14:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/36f64ab3c9ca

Added tag jdk7u6-b12 for changeset f08a3a0e60c3

! .hgtags

Changeset: d8fb2e80e074
Author:    amurillo
Date:      2012-05-25 13:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d8fb2e80e074

7171852: new hotspot build - hs23.2-b04
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: e61e3c378ed4
Author:    dcubed
Date:      2012-05-24 13:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e61e3c378ed4

Merge

! make/solaris/makefiles/defs.make
! make/windows/makefiles/defs.make

Changeset: b22382ddcb66
Author:    dcubed
Date:      2012-05-30 06:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b22382ddcb66

Merge


Changeset: 7a8d3cd65621
Author:    amurillo
Date:      2012-06-01 12:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7a8d3cd65621

7173635: jprt.properties should include release jdk7u6
Reviewed-by: jcoomes

! make/jprt.properties

Changeset: 1b29050f6ab8
Author:    amurillo
Date:      2012-06-01 12:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1b29050f6ab8

Added tag hs23.2-b04 for changeset 7a8d3cd65621

! .hgtags

Changeset: 28746e6d615f
Author:    amurillo
Date:      2012-06-01 12:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/28746e6d615f

Merge

! .hgtags
! make/hotspot_version

Changeset: 25ed7b390a12
Author:    katleman
Date:      2012-06-06 18:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/25ed7b390a12

Added tag jdk7u6-b13 for changeset 28746e6d615f

! .hgtags

Changeset: 6ede6e312f74
Author:    amurillo
Date:      2012-06-01 12:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6ede6e312f74

7173436: new hotspot build - hs23.2-b05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 4cbb838572a3
Author:    mikael
Date:      2012-06-01 20:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4cbb838572a3

7155453: [macosx] re-enable jbb tests in JPRT
Summary: Run SPECjbb in headless mode and enable SPECjbb runs on OSX
Reviewed-by: dcubed, dholmes

! make/jprt.properties

Changeset: 2c04ea9341f9
Author:    mikael
Date:      2012-06-06 05:21 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2c04ea9341f9

7170275: os::print_os_info needs to know about Windows 8
Summary: Recognize Windows 8 and Windows Server 2012
Reviewed-by: sla, kvn, azeemj

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

Changeset: ed206bb84d16
Author:    fparain
Date:      2012-06-07 05:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ed206bb84d16

7171703: JNI DefineClass crashes client VM when first parameter is NULL
Reviewed-by: acorn, kamg, sspitsyn, dholmes

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

Changeset: 1bc0c1354c4d
Author:    kamg
Date:      2012-06-04 10:22 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1bc0c1354c4d

7166498: JVM crash in ClassVerifier
Summary: Fixed raw pointer being used after potential safepoint/GC
Reviewed-by: acorn, fparain, dholmes

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

Changeset: 168536dbae60
Author:    kamg
Date:      2012-06-07 10:36 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/168536dbae60

Merge


Changeset: 202880d633e6
Author:    twisti
Date:      2012-05-25 11:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/202880d633e6

7170145: C1 doesn't respect the JMM with volatile field loads
Reviewed-by: kvn, roland

! src/share/vm/c1/c1_ValueMap.hpp

Changeset: f681327b10b6
Author:    amurillo
Date:      2012-06-08 12:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f681327b10b6

Added tag hs23.2-b05 for changeset 202880d633e6

! .hgtags

Changeset: 6b0f17814138
Author:    amurillo
Date:      2012-06-08 13:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6b0f17814138

Merge

! .hgtags
! make/hotspot_version
! src/os/windows/vm/os_windows.cpp

Changeset: 55e66d61e481
Author:    katleman
Date:      2012-06-14 15:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/55e66d61e481

Added tag jdk7u6-b14 for changeset 6b0f17814138

! .hgtags

Changeset: e5f7f95411fb
Author:    asaha
Date:      2012-03-06 10:21 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e5f7f95411fb

7151573: Fork hs23.1 hsx from hs23.0 for 7u5 and reinitialize build number
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 06a8c35d1d2a
Author:    katleman
Date:      2012-03-07 15:49 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/06a8c35d1d2a

Added tag jdk7u5-b01 for changeset e5f7f95411fb

! .hgtags

Changeset: 74887fa0c368
Author:    asaha
Date:      2012-03-16 14:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/74887fa0c368

Merge

! .hgtags
! make/hotspot_version

Changeset: 149b6bbf77ff
Author:    asaha
Date:      2012-03-23 10:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/149b6bbf77ff

Merge

! .hgtags
! make/hotspot_version

Changeset: 6a7aac2ae8db
Author:    kamg
Date:      2012-03-29 13:22 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6a7aac2ae8db

7110720: Issue with vm config file loadingIssue with vm config file loading
Summary: disabling default config files if -XX:-ReadDefaultConfigFiles
Reviewed-by: phh, jrose, dcubed, dholmes

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/arguments.cpp
+ test/runtime/7110720/Test7110720.sh

Changeset: 5d7066bade31
Author:    asaha
Date:      2012-03-30 09:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5d7066bade31

Merge

! .hgtags
! make/hotspot_version

Changeset: fc1294d2611b
Author:    asaha
Date:      2012-03-30 11:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fc1294d2611b

7158116: Bump the hs23.1 build number to b02
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: aa04a01605ea
Author:    asaha
Date:      2012-03-30 11:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aa04a01605ea

Merge

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

Changeset: 549ba5646494
Author:    never
Date:      2012-04-04 20:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/549ba5646494

7152811: Issues in client compiler
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciField.hpp

Changeset: 5b2d6cfb602b
Author:    asaha
Date:      2012-04-06 14:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5b2d6cfb602b

Merge

! .hgtags
! make/hotspot_version

Changeset: dcf91dc1f50e
Author:    never
Date:      2012-04-11 17:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dcf91dc1f50e

7160677: missing else in fix for 7152811
Reviewed-by: kvn

! src/share/vm/ci/ciField.cpp

Changeset: dc978aca3ceb
Author:    asaha
Date:      2012-04-12 15:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dc978aca3ceb

Merge

! .hgtags
! make/hotspot_version

Changeset: db2b0f27fea1
Author:    katleman
Date:      2012-04-13 13:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/db2b0f27fea1

Added tag jdk7u5-b02 for changeset dc978aca3ceb

! .hgtags

Changeset: 93ec23d55b87
Author:    katleman
Date:      2012-04-16 15:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/93ec23d55b87

Added tag jdk7u4-b30 for changeset c7c6b00122cf

! .hgtags

Changeset: 1eb9f79307a8
Author:    katleman
Date:      2012-04-20 11:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1eb9f79307a8

Added tag jdk7u4-b21 for changeset 93ec23d55b87

! .hgtags

Changeset: dcfa1289a007
Author:    asaha
Date:      2012-04-23 13:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dcfa1289a007

Merge

! .hgtags

Changeset: add74a570ab2
Author:    asaha
Date:      2012-04-23 14:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/add74a570ab2

7163621: Bump the hs23.1 build number to b03
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: bf2255796a93
Author:    kamg
Date:      2012-05-03 15:57 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bf2255796a93

7160757: Problem with hotspot/runtime_classfile
Summary: Allow only current and super invokespecials of <init>
Reviewed-by: never, coleenp, dcubed

! src/share/vm/classfile/verifier.cpp
+ test/runtime/7160757/Test7160757.java

Changeset: aed9d0f0f050
Author:    katleman
Date:      2012-05-07 12:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aed9d0f0f050

Added tag jdk7u4-b22 for changeset 1eb9f79307a8

! .hgtags

Changeset: f11f0f1db115
Author:    katleman
Date:      2012-05-07 14:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f11f0f1db115

Added tag jdk7u4-b31 for changeset aed9d0f0f050

! .hgtags

Changeset: 9ed92188eccc
Author:    asaha
Date:      2012-05-08 10:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9ed92188eccc

Merge

! .hgtags

Changeset: 6024bdfed9bf
Author:    asaha
Date:      2012-05-08 11:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6024bdfed9bf

Merge

! .hgtags

Changeset: 42ee6a26a543
Author:    katleman
Date:      2012-05-10 09:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/42ee6a26a543

Added tag jdk7u5-b04 for changeset 6024bdfed9bf

! .hgtags

Changeset: 6434cb74457e
Author:    katleman
Date:      2012-05-16 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6434cb74457e

Added tag jdk7u5-b05 for changeset 42ee6a26a543

! .hgtags

Changeset: 562c9e5ed2f8
Author:    katleman
Date:      2012-05-24 13:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/562c9e5ed2f8

Added tag jdk7u5-b30 for changeset 6434cb74457e

! .hgtags

Changeset: ced728021cf5
Author:    asaha
Date:      2012-06-15 13:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ced728021cf5

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/classfile/verifier.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: a3b7e95435f5
Author:    vita
Date:      2012-06-22 16:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a3b7e95435f5

Added tag jdk7u6-b15 for changeset ced728021cf5

! .hgtags

Changeset: 76aaf8ba8e18
Author:    amurillo
Date:      2012-06-08 13:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/76aaf8ba8e18

7175516: new hotspot build - hs23.2-b06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 7871a1b632cb
Author:    dholmes
Date:      2012-06-08 02:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7871a1b632cb

7172708: 32/64 bit type issues on Windows after Mac OS X port
Reviewed-by: dholmes, coleenp
Contributed-by: Chris Dennis <cdennis at terracottatech.com>

! src/share/vm/utilities/globalDefinitions_visCPP.hpp

Changeset: d3c927eb9f1e
Author:    amurillo
Date:      2012-06-15 13:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d3c927eb9f1e

Added tag hs23.2-b06 for changeset 7871a1b632cb

! .hgtags

Changeset: 024a95fd5933
Author:    amurillo
Date:      2012-06-15 13:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/024a95fd5933

7177365: new hotspot build - hs23.2-b07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 5d718ef6233b
Author:    poonam
Date:      2012-06-14 02:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5d718ef6233b

6310967: SA: jstack -m produce failures in output
Summary: While looking for the sender frame check that the frame pointer should not be less than the stack pointer.
Reviewed-by: dholmes, sla

! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/sparc/LinuxSPARCCFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcCFrame.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java

Changeset: dc333950f54f
Author:    twisti
Date:      2012-06-11 16:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dc333950f54f

7063674: Wrong results from basic comparisons after calls to Long.bitCount(long)
Reviewed-by: kvn

! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad

Changeset: ce8d9e20eded
Author:    twisti
Date:      2012-06-13 11:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ce8d9e20eded

7174928: JSR 292: unresolved invokedynamic call sites deopt and osr infinitely
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp

Changeset: ea9e0c74b03f
Author:    kvn
Date:      2012-06-11 14:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ea9e0c74b03f

7174510: 19 JCK compiler tests fail with C2 error: memNode.cpp:812 - ShouldNotReachHere
Summary: Add missing check for EncodeP node in MemNode::Ideal_common_DU_postCCP() method.
Reviewed-by: twisti

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

Changeset: 7cfb7d4b1e17
Author:    kvn
Date:      2012-06-12 09:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7cfb7d4b1e17

7169782: C2: SIGSEGV in LShiftLNode::Ideal(PhaseGVN*, bool)
Summary: keep intermediate node alive till the end of the graph construction using dummy hook node trick
Reviewed-by: kvn, twisti
Contributed-by: vladimir.x.ivanov at oracle.com

! src/share/vm/opto/divnode.cpp
+ test/compiler/6732154/Test6732154.java
+ test/compiler/7169782/Test7169782.java

Changeset: dd22c97d7663
Author:    collins
Date:      2012-06-19 21:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dd22c97d7663

7178113: build environment change
Summary: Simple change to enable proper builds of arm target
Reviewed-by: ohair, dholmes

! make/jprt.properties

Changeset: 7f6110bb70da
Author:    collins
Date:      2012-06-20 03:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7f6110bb70da

Merge


Changeset: 30fd0e13dd48
Author:    coleenp
Date:      2012-06-20 09:57 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/30fd0e13dd48

7158800: Improve storage of symbol tables
Summary: Use an alternate version of hashing algorithm for symbol string tables and after a certain bucket size to improve performance
Reviewed-by: pbk, kamg, dlong, kvn, fparain

+ src/share/vm/classfile/altHashing.cpp
+ src/share/vm/classfile/altHashing.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/memory/dump.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp
! src/share/vm/utilities/hashtable.inline.hpp
+ test/runtime/7158800/BadUtf8.java
+ test/runtime/7158800/InternTest.java
+ test/runtime/7158800/Test7158800.sh
+ test/runtime/7158800/badstrings.txt

Changeset: d4b7661ee0b4
Author:    coleenp
Date:      2012-06-20 07:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d4b7661ee0b4

Merge


Changeset: 7438d28f02dc
Author:    dcubed
Date:      2012-06-20 14:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7438d28f02dc

Merge


Changeset: afeeb6cc68ac
Author:    jiangli
Date:      2012-06-20 19:12 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/afeeb6cc68ac

7120481: storeStore barrier in constructor with final field
Summary: Issue storestore barrier before constructor return if the constructor write final field.
Reviewed-by: dholmes, jrose, roland, coleenp

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_ValueMap.hpp

Changeset: 68ccf3f6d053
Author:    jiangli
Date:      2012-06-20 20:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/68ccf3f6d053

Merge


Changeset: 01c6624127b5
Author:    vladidan
Date:      2012-06-20 15:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/01c6624127b5

7129401: PPC: runtime/7100935/TestShortArraycopy.java fails
Summary: pass assembler switches for PPC
Reviewed-by: dholmes

! make/linux/makefiles/ppc.make

Changeset: d1c1573de6ca
Author:    vladidan
Date:      2012-06-21 06:11 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d1c1573de6ca

Merge


Changeset: f98a4f0bf62a
Author:    amurillo
Date:      2012-06-22 13:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f98a4f0bf62a

Added tag hs23.2-b07 for changeset d1c1573de6ca

! .hgtags

Changeset: cefe884c708a
Author:    amurillo
Date:      2012-06-26 16:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cefe884c708a

Merge

! .hgtags
! make/hotspot_version

Changeset: c4dedc59d44d
Author:    katleman
Date:      2012-06-27 17:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c4dedc59d44d

Added tag jdk7u6-b16 for changeset cefe884c708a

! .hgtags

Changeset: 409abd911542
Author:    amurillo
Date:      2012-06-22 13:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/409abd911542

7179194: new hotspot build - hs23.2-b08
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: faa8d30306e8
Author:    coleenp
Date:      2012-06-26 09:52 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/faa8d30306e8

7178670: runtime/7158800/BadUtf8.java fails in SymbolTable::rehash_table
Summary: Cannot delete _buckets and HashtableEntries in shared space (CDS)
Reviewed-by: acorn, kvn, dlong, dcubed, kamg

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp

Changeset: abddf1ce3c6b
Author:    roland
Date:      2012-06-18 09:52 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/abddf1ce3c6b

7174363: Arrays.copyOfRange leads to VM crash with -Xcomp -server if executed by testing framework
Summary: Arrays.copyOfRange(original, from, to) with from > original.length tries to do a copy with a negative length.
Reviewed-by: kvn, twisti

! src/share/vm/opto/library_call.cpp
+ test/compiler/7174363/Test7174363.java

Changeset: 9fc5bd0e5818
Author:    twisti
Date:      2012-06-18 15:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9fc5bd0e5818

7157365: jruby/bench.bench_timeout crashes with JVM internal error
Reviewed-by: jrose, kvn

! src/share/vm/memory/universe.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/type.cpp

Changeset: b237d00f078c
Author:    roland
Date:      2012-06-21 09:52 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b237d00f078c

7129715: MAC: SIGBUS in nsk stress test
Summary: StackOverflowError may get lost on OSX.
Reviewed-by: kvn, dcubed

! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp

Changeset: cfb193817fec
Author:    kvn
Date:      2012-06-26 09:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cfb193817fec

7179138: Incorrect result with String concatenation optimization
Summary: check for and skip diamond shaped NULL check code for the result of toString()
Reviewed-by: twisti, roland

! src/share/vm/opto/stringopts.cpp
+ test/compiler/7179138/Test7179138_1.java
+ test/compiler/7179138/Test7179138_2.java

Changeset: 981f551d0f91
Author:    coleenp
Date:      2012-06-29 14:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/981f551d0f91

7179759: ENV: Nightly fails during jdk copiyng for solaris platforms after FDS unzipping
Summary: libjvm_g_db.so and libjvm_g_dtrace.so links in .diz file still had 64 directory
Reviewed-by: kamg, dholmes, sspitsyn

! make/solaris/makefiles/dtrace.make

Changeset: 270a40a57b3d
Author:    amurillo
Date:      2012-06-29 15:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/270a40a57b3d

Merge

! make/hotspot_version

Changeset: 7a37cec9d0d4
Author:    amurillo
Date:      2012-06-29 15:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7a37cec9d0d4

Added tag hs23.2-b08 for changeset 270a40a57b3d

! .hgtags

Changeset: df0df4ae5af2
Author:    katleman
Date:      2012-07-05 23:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/df0df4ae5af2

Added tag jdk7u6-b17 for changeset 7a37cec9d0d4

! .hgtags

Changeset: 1257f4373a06
Author:    katleman
Date:      2012-07-06 15:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1257f4373a06

Added tag jdk7u6-b18 for changeset df0df4ae5af2

! .hgtags

Changeset: 0aea8f0afd27
Author:    katleman
Date:      2012-07-11 11:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0aea8f0afd27

Added tag jdk7u6-b19 for changeset 1257f4373a06

! .hgtags

Changeset: 43fe30b725f2
Author:    amurillo
Date:      2012-06-29 16:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/43fe30b725f2

7180884: new hotspot build - hs23.2-b09
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ab0720e5abbb
Author:    dlong
Date:      2012-06-25 15:34 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ab0720e5abbb

7156729: PPC: R_PPC_REL24 relocation error related to some libraries built without -fPIC
Summary: build powerpc with -fPIC
Reviewed-by: mikael, vladidan, roland
Contributed-by: dean.long at oracle.com

! make/pic.make

Changeset: 3f142ec74a26
Author:    kamg
Date:      2012-07-09 18:03 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3f142ec74a26

7167142: Consider a warning when finding a .hotspotrc or .hotspot_compiler file that isn't used
Summary: Send warnings to output stream
Reviewed-by: dholmes, fparain

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

Changeset: 571bc10e2a37
Author:    kamg
Date:      2012-07-11 09:17 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/571bc10e2a37

7181200: JVM new hashing code breaks SA in product mode
Summary: Made new_hash() overloaded rather than a virtual function so SA code doesn't need to be changed.
Reviewed-by: kvn, acorn, dholmes, fparain
Contributed-by: coleen.phillimore at oracle.com

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp

Changeset: cfb2ea9dfefd
Author:    minqi
Date:      2012-06-22 15:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cfb2ea9dfefd

7175133: jinfo failed to get system properties after 6924259
Summary: String offset and count fields as fix of 6924259 were removed, and become optional. SA still use offset and count fields to read String contents and failed. Fix if they exist, use them other then use value field only to read, this keeps consistent with the changes in 6924259.
Reviewed-by: dholmes, mikael
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java

Changeset: a4b60109cffc
Author:    minqi
Date:      2012-06-22 15:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a4b60109cffc

7177128: SA cannot get correct system properties after 7126277
Summary: Bug fix of 7126277 changed hashing algorithm and also changed key as final field, this led SA unable to set correct value for key. Solution by reading key/value and insert them into the new table.
Reviewed-by: dholmes, mikael
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java

Changeset: a0c2fa4baeb6
Author:    amurillo
Date:      2012-07-13 13:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a0c2fa4baeb6

Merge


Changeset: 1e31ae50c2cf
Author:    amurillo
Date:      2012-07-13 13:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1e31ae50c2cf

Added tag hs23.2-b09 for changeset a0c2fa4baeb6

! .hgtags

Changeset: 02a6c89432d7
Author:    katleman
Date:      2012-07-18 16:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/02a6c89432d7

Added tag jdk7u6-b20 for changeset 1e31ae50c2cf

! .hgtags

Changeset: 528502f93096
Author:    katleman
Date:      2012-07-31 10:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/528502f93096

Added tag jdk7u8-b01 for changeset 02a6c89432d7

! .hgtags

Changeset: 517811ece630
Author:    katleman
Date:      2012-08-06 15:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/517811ece630

Added tag jdk7u8-b02 for changeset 528502f93096

! .hgtags

Changeset: a79d86eef6ac
Author:    cl
Date:      2012-07-27 16:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a79d86eef6ac

Added tag jdk7u6-b21 for changeset 02a6c89432d7

! .hgtags

Changeset: df57f6208cb7
Author:    katleman
Date:      2012-08-01 19:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/df57f6208cb7

Added tag jdk7u6-b22 for changeset a79d86eef6ac

! .hgtags

Changeset: b03c2687fb16
Author:    katleman
Date:      2012-08-07 12:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b03c2687fb16

Added tag jdk7u6-b23 for changeset df57f6208cb7

! .hgtags

Changeset: db63a909e1ad
Author:    asaha
Date:      2012-08-07 14:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/db63a909e1ad

Merge

! .hgtags

Changeset: 37115e4d43fd
Author:    katleman
Date:      2012-08-13 14:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/37115e4d43fd

Added tag jdk7u8-b03 for changeset db63a909e1ad

! .hgtags

Changeset: aff265cb73a3
Author:    dcubed
Date:      2012-08-02 14:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aff265cb73a3

7188168: 7071904 broke the DEBUG_BINARIES option on Linux
Summary: Change DEBUG_BINARIES option logic to be more clear.
Reviewed-by: fparain, andrew

! make/linux/makefiles/adlc.make
! make/linux/makefiles/gcc.make

Changeset: bd31256d38e3
Author:    amurillo
Date:      2012-08-21 13:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bd31256d38e3

Merge


Changeset: fa6db704402b
Author:    amurillo
Date:      2012-08-08 15:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fa6db704402b

7190118: new hotspot build - hs23.4-b01
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 4a399ea48e58
Author:    amurillo
Date:      2012-08-08 16:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4a399ea48e58

7189729: jprt.properties should include release jdk7u8
Reviewed-by: jcoomes

! make/jprt.properties

Changeset: d76178dc479c
Author:    amurillo
Date:      2012-08-08 16:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d76178dc479c

7190130: make jdk7u8 the default jprt release for hs23.4
Reviewed-by: jcoomes

! make/jprt.properties

Changeset: 0948731ccc7f
Author:    amurillo
Date:      2012-08-21 13:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0948731ccc7f

Merge


Changeset: e83de0a17c98
Author:    katleman
Date:      2012-08-22 17:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e83de0a17c98

Added tag jdk7u8-b04 for changeset 0948731ccc7f

! .hgtags

Changeset: 037c44a259bc
Author:    kevinw
Date:      2012-04-20 14:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/037c44a259bc

7162488: VM not printing unknown -XX options
Reviewed-by: dholmes, kamg

! src/share/vm/runtime/arguments.cpp
+ test/runtime/7162488/Test7162488.sh

Changeset: 21e264867795
Author:    amurillo
Date:      2012-08-24 13:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/21e264867795

Merge


Changeset: baaa29c3d798
Author:    amurillo
Date:      2012-08-24 13:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/baaa29c3d798

Added tag hs23.4-b01 for changeset 21e264867795

! .hgtags

Changeset: 6e9aa487055f
Author:    katleman
Date:      2012-08-29 15:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6e9aa487055f

Added tag jdk7u8-b05 for changeset baaa29c3d798

! .hgtags

Changeset: cffde29ea7cc
Author:    katleman
Date:      2012-08-10 10:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cffde29ea7cc

Added tag jdk7u6-b24 for changeset b03c2687fb16

! .hgtags

Changeset: 7566374c3c89
Author:    katleman
Date:      2012-08-13 14:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7566374c3c89

Added tag jdk7u6-b30 for changeset cffde29ea7cc

! .hgtags

Changeset: f7933fecea9a
Author:    asaha
Date:      2012-08-28 14:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f7933fecea9a

7179908: Fork hs23.3 hsx from hs22.2 for jdk7u7 and reinitialize build number
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: eeef33dc4b40
Author:    katleman
Date:      2012-08-29 10:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/eeef33dc4b40

Added tag jdk7u7-b10 for changeset f7933fecea9a

! .hgtags

Changeset: f1551c70c7f5
Author:    katleman
Date:      2012-08-29 14:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f1551c70c7f5

Added tag jdk7u7-b30 for changeset eeef33dc4b40

! .hgtags

Changeset: dc6893023f11
Author:    asaha
Date:      2012-08-29 22:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dc6893023f11

Merge

! .hgtags
! make/hotspot_version

Changeset: cf0013b9698c
Author:    katleman
Date:      2012-09-05 15:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cf0013b9698c

Added tag jdk7u10-b06 for changeset dc6893023f11

! .hgtags

Changeset: 90893ad8345d
Author:    amurillo
Date:      2012-08-24 13:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/90893ad8345d

7192847: new hotspot build - hs23.4-b02
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1864d470cd19
Author:    jprovino
Date:      2012-08-25 15:12 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1864d470cd19

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

! make/pic.make

Changeset: 36784fde7080
Author:    jcoomes
Date:      2012-09-08 00:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/36784fde7080

7197106: renumber hs23.4 to hs23.6
Reviewed-by: johnc

! .hgtags
! make/hotspot_version

Changeset: 6f4d80025149
Author:    jcoomes
Date:      2012-09-08 08:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6f4d80025149

Merge

! .hgtags
! make/hotspot_version

Changeset: 5f67ff71653f
Author:    jcoomes
Date:      2012-09-08 08:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5f67ff71653f

Added tag hs23.6-b02 for changeset 6f4d80025149

! .hgtags

Changeset: 40d69350d419
Author:    katleman
Date:      2012-09-13 12:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/40d69350d419

Added tag jdk7u10-b07 for changeset 5f67ff71653f

! .hgtags

Changeset: dd467a878e9e
Author:    jcoomes
Date:      2012-09-08 08:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dd467a878e9e

7197100: new hotspot build - hs23.6-b03
Reviewed-by: johnc

! make/hotspot_version

Changeset: 4c7cbf84d9a3
Author:    roland
Date:      2012-08-22 14:29 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4c7cbf84d9a3

7171824: assert(_offset >= 1) failed: illegal call to offset()
Summary: C1 value numbering hits unloaded klass.
Reviewed-by: kvn, twisti

! src/share/vm/c1/c1_ValueMap.cpp
! src/share/vm/c1/c1_ValueMap.hpp

Changeset: f50e0fcc77bb
Author:    amurillo
Date:      2012-09-13 11:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f50e0fcc77bb

7198338: make jdk7u10 the default jprt release for hs23.6
Reviewed-by: jcoomes

! make/jprt.properties

Changeset: 0b8461989634
Author:    fparain
Date:      2012-09-14 07:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0b8461989634

6294277: java -Xdebug crashes on SourceDebugExtension attribute larger than 64K
Reviewed-by: sspitsyn, dholmes, coleenp, kamg

! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/vmStructs.cpp
+ test/runtime/6294277/SourceDebugExtension.java

Changeset: 042438023396
Author:    amurillo
Date:      2012-09-14 14:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/042438023396

Merge


Changeset: 4c525a19affa
Author:    amurillo
Date:      2012-09-14 14:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4c525a19affa

Added tag hs23.6-b03 for changeset 042438023396

! .hgtags

Changeset: d14ad18fc516
Author:    katleman
Date:      2012-09-20 19:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d14ad18fc516

Added tag jdk7u10-b08 for changeset 4c525a19affa

! .hgtags

Changeset: 21a84336cab3
Author:    katleman
Date:      2012-09-26 21:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/21a84336cab3

Added tag jdk7u10-b09 for changeset d14ad18fc516

! .hgtags

Changeset: 4767c78f3504
Author:    amurillo
Date:      2012-10-20 00:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4767c78f3504

Merge

! .hgtags
! .jcheck/conf
- agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java
! make/hotspot_version
! make/jprt.properties
! make/linux/makefiles/gcc.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/defs.make
! make/windows/makefiles/defs.make
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/compiler/compilerOracle.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/dump.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
- src/share/vm/prims/methodHandleWalk.cpp
- src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp
! src/share/vm/utilities/vmError.cpp
! test/runtime/6294277/SourceDebugExtension.java

Changeset: f2b48605f612
Author:    amurillo
Date:      2012-10-20 00:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f2b48605f612

Added tag hs24-b23 for changeset 4767c78f3504

! .hgtags


From john.coomes at oracle.com  Sat Oct 20 18:37:32 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Sun, 21 Oct 2012 01:37:32 +0000
Subject: hg: hsx/hsx24/hotspot: 8001175: new hotspot build - hs24-b24
Message-ID: <20121021013737.B92BE4747C@hg.openjdk.java.net>

Changeset: 24b36979876f
Author:    amurillo
Date:      2012-10-20 00:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/24b36979876f

8001175: new hotspot build - hs24-b24
Reviewed-by: jcoomes

! make/hotspot_version


From david.holmes at oracle.com  Sun Oct 21 19:23:48 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 22 Oct 2012 12:23:48 +1000
Subject: Default methods for jdk8: request for code review
In-Reply-To: <5081385B.2010207@oracle.com>
References: <5075AC78.3030702@oracle.com> <5081385B.2010207@oracle.com>
Message-ID: <5084AE34.3030209@oracle.com>

Hi Keith,

I'm afraid that is far too extensive a set of changes to provide an 
actual Review on. I've read the design doc and flicked through the code, 
but that's as far as I can go.

One concern I do have:

src/share/vm/utilities/growableArray.hpp

You changed the at(i) access methods to return an object reference 
rather than (I presume) a copy. But is that a safe change to make?

Other general comments:

src/share/vm/runtime/reflection.cpp
src/share/vm/classfile/systemDictionary.hpp
src/share/vm/classfile/vmSymbols.hpp

The changes here doesn't seem to be related to default methods.

---

src/share/vm/oops/method.hpp

Would it be worthwhile defining "MethodType methodType()" directly 
rather than is_overpass() and avoid the bool to MethodType conversion 
when calling allocate() ?

---

src/share/vm/classfile/classFileParser.cpp

Some of your line reformatting is making things more obscure and 
inconsistent in my view. Eg I find this:

   klassVtable::compute_vtable_size_and_num_mirandas(vtable_size,
                                                     num_miranda_methods,
                                                     super_klass(),
                                                     methods,
                                                     access_flags,
                                                     class_loader,
                                                     class_name,
                                                     local_interfaces,
                                                     CHECK_(nullHandle));

much clearer than:

   klassVtable::compute_vtable_size_and_num_mirandas(
       &vtable_size, &num_miranda_methods, &all_mirandas, super_klass(), 
methods,
       access_flags, class_loader, class_name, local_interfaces,
                                                     CHECK_(nullHandle));

Ditto for changes elsewhere eg src/share/vm/oops/klassVtable.cpp

---

src/share/vm/classfile/classFileParser.hpp

+                                 bool* has_default_methods,
+                                 bool* has_default_method,

why the inconsistency in the plurality of the name?

---

src/share/vm/oops/instanceKlass.cpp

Interfaces are still stateless so what initialization is required? Are 
these synthetic initialization routines inserted by javac?

David
-----

On 19/10/2012 9:24 PM, Keith McGuigan wrote:
>
> Anyone?
>
> On 10/10/2012 1:12 PM, Keith McGuigan wrote:
>> Hello,
>>
>> I'd like any review of the code which implements default methods in the
>> JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and
>> tracked by CR 7200776.
>>
>> The design and implementation is described in this short document:
>> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>>
>> And the code is here:
>> http://cr.openjdk.java.net/~kamg/default_methods/
>>
>> Any review (even partial) would be appreciated.  Thanks!
>>
>> --
>> - Keith
>

From volker.simonis at gmail.com  Mon Oct 22 00:42:25 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 22 Oct 2012 09:42:25 +0200
Subject: hg: hsx/hsx24/hotspot: 8001192: allow duplicate bug ids in hs24
In-Reply-To: <20121019233937.4043447466@hg.openjdk.java.net>
References: <20121019233937.4043447466@hg.openjdk.java.net>
Message-ID: <CA+3eh130XCnG_keCOX12+qbtT1KTyR2Wwt_aVpAR=V_QX+rjgQ@mail.gmail.com>

Hi,

could you please explain why we need duplicate bug ids in hsx24?
Apparently this was not necessary for hsx23.

Regards,
Volker

On Sat, Oct 20, 2012 at 1:39 AM,  <alejandro.murillo at oracle.com> wrote:
> Changeset: 81d17d9ab7c9
> Author:    amurillo
> Date:      2012-10-19 16:37 -0700
> URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/81d17d9ab7c9
>
> 8001192: allow duplicate bug ids in hs24
> Reviewed-by: jcoomes
>
> ! .jcheck/conf
>

From david.holmes at oracle.com  Mon Oct 22 04:42:27 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 22 Oct 2012 21:42:27 +1000
Subject: hg: hsx/hsx24/hotspot: 8001192: allow duplicate bug ids in hs24
In-Reply-To: <CA+3eh130XCnG_keCOX12+qbtT1KTyR2Wwt_aVpAR=V_QX+rjgQ@mail.gmail.com>
References: <20121019233937.4043447466@hg.openjdk.java.net>
	<CA+3eh130XCnG_keCOX12+qbtT1KTyR2Wwt_aVpAR=V_QX+rjgQ@mail.gmail.com>
Message-ID: <50853123.5030404@oracle.com>

On 22/10/2012 5:42 PM, Volker Simonis wrote:
> Hi,
>
> could you please explain why we need duplicate bug ids in hsx24?

The same reason as needed in other hsx version: changesets covering the 
same bugids can come in from different paths. The fixes are the same bit 
they are distinct changesets.

> Apparently this was not necessary for hsx23.

I think you will find it is necessary in most of the hsx families.

David

>
> Regards,
> Volker
>
> On Sat, Oct 20, 2012 at 1:39 AM,<alejandro.murillo at oracle.com>  wrote:
>> Changeset: 81d17d9ab7c9
>> Author:    amurillo
>> Date:      2012-10-19 16:37 -0700
>> URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/81d17d9ab7c9
>>
>> 8001192: allow duplicate bug ids in hs24
>> Reviewed-by: jcoomes
>>
>> ! .jcheck/conf
>>

From staffan.larsen at oracle.com  Mon Oct 22 05:14:04 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 22 Oct 2012 14:14:04 +0200
Subject: CFV: New HSX Committer: Nils Loodin
Message-ID: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>

I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.

Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8 
changesets to the HSX project and he is qualified to be committer [1]:

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin

Votes are due by Nov 5, 2012.

Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Thanks,
Staffan Larsen

[1] http://openjdk.java.net/projects/#project-committer
[2] http://openjdk.java.net/census#hsx
[3] http://openjdk.java.net/projects#committer-vote


From bengt.rutisson at oracle.com  Mon Oct 22 05:31:42 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 22 Oct 2012 14:31:42 +0200
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <50853CAE.5050108@oracle.com>


Vote: yes

Bengt

On 2012-10-22 14:14, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>


From keith.mcguigan at oracle.com  Mon Oct 22 05:41:23 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Mon, 22 Oct 2012 08:41:23 -0400
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <50853EF3.4080501@oracle.com>

Vote: yes

On 10/22/2012 8:14 AM, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From christian.tornqvist at oracle.com  Mon Oct 22 05:47:02 2012
From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=)
Date: Mon, 22 Oct 2012 05:47:02 -0700 (PDT)
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <909b066d-1e82-4c20-92df-ee06c6cc587d@default>

Vote: yes

-----Original Message-----
From: Staffan Larsen 
Sent: den 22 oktober 2012 14:14
To: hotspot-dev developers
Subject: CFV: New HSX Committer: Nils Loodin

I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.

Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin

Votes are due by Nov 5, 2012.

Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Thanks,
Staffan Larsen

[1] http://openjdk.java.net/projects/#project-committer
[2] http://openjdk.java.net/census#hsx
[3] http://openjdk.java.net/projects#committer-vote


From daniel.daugherty at oracle.com  Mon Oct 22 06:00:10 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 22 Oct 2012 07:00:10 -0600
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <5085435A.9030109@oracle.com>

Vote: yes

Dan

On 10/22/12 6:14 AM, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From volker.simonis at gmail.com  Mon Oct 22 06:00:19 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 22 Oct 2012 15:00:19 +0200
Subject: hg: hsx/hsx24/hotspot: 8001192: allow duplicate bug ids in hs24
In-Reply-To: <50853123.5030404@oracle.com>
References: <20121019233937.4043447466@hg.openjdk.java.net>
	<CA+3eh130XCnG_keCOX12+qbtT1KTyR2Wwt_aVpAR=V_QX+rjgQ@mail.gmail.com>
	<50853123.5030404@oracle.com>
Message-ID: <CA+3eh1136dcP1MeU2M4xdwxzC1FUZeosEVXZDu8TKPbV2XQfYg@mail.gmail.com>

On Mon, Oct 22, 2012 at 1:42 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 22/10/2012 5:42 PM, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please explain why we need duplicate bug ids in hsx24?
>
>
> The same reason as needed in other hsx version: changesets covering the same
> bugids can come in from different paths. The fixes are the same bit they are
> distinct changesets.
>

Yes, but this is something I don't understand. Why don't you use
different bug IDs for different changesets?
Anyway you create new bug IDs for backports and other codelines (those
starting with 2xxxxxx). So why not using them when checking in such
'distinct changesets' into other codelines?
Additionally, it is not always true that  the fixes are "really" the
same. Sometimes they have to be adapted (e.g. when they are backported
from the hsx main-line to an older hsxYY stabilization code line).
Having different bug IDs for such changes would make thinks a lot
clearer from my point of view.

Regards,
Volker

>> Apparently this was not necessary for hsx23.
>
>
> I think you will find it is necessary in most of the hsx families.
>
> David
>
>
>>
>> Regards,
>> Volker
>>
>> On Sat, Oct 20, 2012 at 1:39 AM,<alejandro.murillo at oracle.com>  wrote:
>>>
>>> Changeset: 81d17d9ab7c9
>>> Author:    amurillo
>>> Date:      2012-10-19 16:37 -0700
>>> URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/81d17d9ab7c9
>>>
>>> 8001192: allow duplicate bug ids in hs24
>>> Reviewed-by: jcoomes
>>>
>>> ! .jcheck/conf
>>>
>

From nils.eliasson at oracle.com  Mon Oct 22 06:00:24 2012
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 22 Oct 2012 15:00:24 +0200
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <50854368.5050600@oracle.com>

Vote: yes

Staffan Larsen skrev 2012-10-22 14:14:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>


From coleen.phillimore at oracle.com  Mon Oct 22 07:13:19 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 22 Oct 2012 10:13:19 -0400
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <5085547F.3070503@oracle.com>

Vote: yes

On 10/22/2012 8:14 AM, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From keith.mcguigan at oracle.com  Mon Oct 22 07:19:18 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Mon, 22 Oct 2012 10:19:18 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <5084AE34.3030209@oracle.com>
References: <5075AC78.3030702@oracle.com> <5081385B.2010207@oracle.com>
	<5084AE34.3030209@oracle.com>
Message-ID: <508555E6.6090106@oracle.com>


Hi David,

Thanks for the feedback!  Comments inline:

On 10/21/2012 10:23 PM, David Holmes wrote:
> Hi Keith,
>
> I'm afraid that is far too extensive a set of changes to provide an
> actual Review on. I've read the design doc and flicked through the code,
> but that's as far as I can go.
>
> One concern I do have:
>
> src/share/vm/utilities/growableArray.hpp
>
> You changed the at(i) access methods to return an object reference
> rather than (I presume) a copy. But is that a safe change to make?

I believe it is (and testing has upheld this so far).  When returning a 
reference (instance of an instance), the copy will be created by the 
caller when the value is returned and assigned.  The only way this could 
cause a problem (I think) is if someone was assigning the result of this 
call to a reference type, which may be illegal since one can't take a 
reference to a temporary.  In any case, we don't use references very 
often in the codebase so this is unlikely to be a problem.

> Other general comments:
>
> src/share/vm/runtime/reflection.cpp
> src/share/vm/classfile/systemDictionary.hpp
> src/share/vm/classfile/vmSymbols.hpp
>
> The changes here doesn't seem to be related to default methods.

Right -- these are changes to support the lambda implementation bundled 
for convenience (and an NPG-292 bugfix that probably isn't needed 
anymore since it's been fixed in the main codebase).

> src/share/vm/oops/method.hpp
>
> Would it be worthwhile defining "MethodType methodType()" directly
> rather than is_overpass() and avoid the bool to MethodType conversion
> when calling allocate() ?

Yes, that's a good idea.  I'll do that, thanks.


> src/share/vm/classfile/classFileParser.cpp
>
> Some of your line reformatting is making things more obscure and
> inconsistent in my view. Eg I find this:
>
>    klassVtable::compute_vtable_size_and_num_mirandas(vtable_size,
>                                                      num_miranda_methods,
>                                                      super_klass(),
>                                                      methods,
>                                                      access_flags,
>                                                      class_loader,
>                                                      class_name,
>                                                      local_interfaces,
>                                                      CHECK_(nullHandle));
>
> much clearer than:
>
>    klassVtable::compute_vtable_size_and_num_mirandas(
>        &vtable_size, &num_miranda_methods, &all_mirandas, super_klass(),
> methods,
>        access_flags, class_loader, class_name, local_interfaces,
>                                                      CHECK_(nullHandle));
>
> Ditto for changes elsewhere eg src/share/vm/oops/klassVtable.cpp

Yeah I can't stand that parameter-passing style and change it whenever I 
can.  The whitespace doesn't add any semantic value or enhance 
documentation at all; it ends up taking up space and making it so you 
can't see as much surrounding context in each screenful.  Plus it 
requires more work for reindentation when there's a change that requires 
it.  Blech.

> ---
>
> src/share/vm/classfile/classFileParser.hpp
>
> +                                 bool* has_default_methods,
> +                                 bool* has_default_method,
>
> why the inconsistency in the plurality of the name?

No good reason.  The first indicates if any of the implemented 
interfaces has any default methods, while the second indicates if 'this' 
class has a default method.  But essentially they're doing the same 
thing -- indicating that the current method has default methods 
somewhere in it's hierarchy (inclusively).

> src/share/vm/oops/instanceKlass.cpp
>
> Interfaces are still stateless so what initialization is required? Are
> these synthetic initialization routines inserted by javac?

Technically we don't need initialization -- what we really need is 
verification (which is done as part of initialization in the 
implementation).  We need to verify the contents of the default methods.

--
- Keith

From Dmitry.Samersoff at oracle.com  Mon Oct 22 07:28:55 2012
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 22 Oct 2012 18:28:55 +0400
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <50853CAE.5050108@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
	<50853CAE.5050108@oracle.com>
Message-ID: <50855827.1080105@oracle.com>

Vote: yes

On 2012-10-22 16:31, Bengt Rutisson wrote:
> 
> Vote: yes
> 
> Bengt
> 
> On 2012-10-22 14:14, Staffan Larsen wrote:
>> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX
>> Committer.
>>
>> Nils is a member of the Hotspot/JDK Serviceability group. He has
>> contributed 8
>> changesets to the HSX project and he is qualified to be committer [1]:
>>
>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>>
>> Votes are due by Nov 5, 2012.
>>
>> Only current HSX Committers [2] are eligible to vote on this
>> nomination.  Votes
>> must be cast in the open by replying to this mailing list.
>>
>> For Lazy Consensus voting instructions, see [3].
>>
>> Thanks,
>> Staffan Larsen
>>
>> [1] http://openjdk.java.net/projects/#project-committer
>> [2] http://openjdk.java.net/census#hsx
>> [3] http://openjdk.java.net/projects#committer-vote
>>
> 


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

From karen.kinnear at oracle.com  Mon Oct 22 07:46:55 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 22 Oct 2012 10:46:55 -0400
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <88A36886-9872-4325-9F12-ED07E202E3D9@oracle.com>

Vote: yes

thanks,
Karen

On Oct 22, 2012, at 8:14 AM, Staffan Larsen wrote:

> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
> 
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8 
> changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
> 
> Votes are due by Nov 5, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Staffan Larsen
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From frederic.parain at oracle.com  Mon Oct 22 08:14:23 2012
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 22 Oct 2012 17:14:23 +0200
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <508562CF.4050707@oracle.com>

Vote: yes

Fred

On 10/22/12 02:14 PM, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at Oracle.com


From vladimir.kozlov at oracle.com  Mon Oct 22 08:18:07 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 22 Oct 2012 08:18:07 -0700
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <49A57E10-2343-4E57-818E-54FF44AAA45F@oracle.com>

Vote: yes

On Oct 22, 2012, at 5:14 AM, Staffan Larsen wrote:

> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
> 
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8 
> changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
> 
> Votes are due by Nov 5, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Staffan Larsen
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From jesper.wilhelmsson at oracle.com  Mon Oct 22 09:30:59 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 22 Oct 2012 18:30:59 +0200
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <508574C3.6080604@oracle.com>

Vote: yes

/Jesper

On 2012-10-22 14:14, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>


From coleen.phillimore at oracle.com  Mon Oct 22 13:50:31 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 22 Oct 2012 20:50:31 +0000
Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets
Message-ID: <20121022205047.35557474A6@hg.openjdk.java.net>

Changeset: 85916677fc22
Author:    coleenp
Date:      2012-10-18 13:08 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/85916677fc22

7188233: UseVMInterruptibleIO flag deprecate for JDK8
Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8.  The flag will still enable Interruptible IO on Solaris, but users will get a warning.
Reviewed-by: dholmes, acorn, alanb
Contributed-by: harold.seigel at oracle.com

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

Changeset: 8ebcedb7604d
Author:    coleenp
Date:      2012-10-18 13:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8ebcedb7604d

7053130: hs_err file does not record specified CLASSPATH
Summary: Added code to write the value of the java.class.path property to the hs_err file.
Reviewed-by: kmo, dholmes, kvn
Contributed-by: harold.seigel at oracle.com

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

Changeset: c7957b458bf8
Author:    minqi
Date:      2012-10-19 08:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c7957b458bf8

8000818: SA constant pool need to reference to reference map after permgen removal
Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java

Changeset: 8eeffbc22f10
Author:    minqi
Date:      2012-10-19 08:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8eeffbc22f10

8001055: Bytes.swap should follow big endian
Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java

Changeset: 716c64bda5ba
Author:    zgu
Date:      2012-10-19 21:40 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/716c64bda5ba

7199092: NMT: NMT needs to deal overlapped virtual memory ranges
Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map.
Reviewed-by: acorn, coleenp

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/handles.inline.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/memBaseline.cpp
! src/share/vm/services/memBaseline.hpp
! src/share/vm/services/memPtr.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memRecorder.cpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memReporter.cpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memSnapshot.cpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: b988bff99b38
Author:    zgu
Date:      2012-10-19 18:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b988bff99b38

Merge


Changeset: 80f44792c0c9
Author:    coleenp
Date:      2012-10-22 12:01 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/80f44792c0c9

Merge



From john.r.rose at oracle.com  Mon Oct 22 14:02:57 2012
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 22 Oct 2012 14:02:57 -0700
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <3EE3687D-5D93-4D63-BD6E-1D8C1BF0AD1A@oracle.com>

Vote: yes

On Oct 22, 2012, at 5:14 AM, Staffan Larsen wrote:

> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.


From christian.thalinger at oracle.com  Mon Oct 22 14:37:59 2012
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Mon, 22 Oct 2012 21:37:59 +0000
Subject: hg: hsx/hotspot-main/jdk: 8000989: smaller code changes to make
	future JSR 292 backports easier
Message-ID: <20121022213840.6F20F474AA@hg.openjdk.java.net>

Changeset: 61af38b8d4ff
Author:    twisti
Date:      2012-10-19 17:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/61af38b8d4ff

8000989: smaller code changes to make future JSR 292 backports easier
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/CallSite.java
! src/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/LambdaForm.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! test/java/lang/invoke/BigArityTest.java
! test/java/lang/invoke/PrivateInvokeTest.java


From christian.thalinger at oracle.com  Mon Oct 22 14:46:45 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 22 Oct 2012 14:46:45 -0700
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <E260FF51-1D9B-45DB-A9A3-F3750454193F@oracle.com>

Vote: yes

On Oct 22, 2012, at 5:14 AM, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
> 
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8 
> changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
> 
> Votes are due by Nov 5, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Staffan Larsen
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
> 


From david.holmes at oracle.com  Mon Oct 22 18:16:54 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 23 Oct 2012 11:16:54 +1000
Subject: hg: hsx/hsx24/hotspot: 8001192: allow duplicate bug ids in hs24
In-Reply-To: <CA+3eh1136dcP1MeU2M4xdwxzC1FUZeosEVXZDu8TKPbV2XQfYg@mail.gmail.com>
References: <20121019233937.4043447466@hg.openjdk.java.net>
	<CA+3eh130XCnG_keCOX12+qbtT1KTyR2Wwt_aVpAR=V_QX+rjgQ@mail.gmail.com>
	<50853123.5030404@oracle.com>
	<CA+3eh1136dcP1MeU2M4xdwxzC1FUZeosEVXZDu8TKPbV2XQfYg@mail.gmail.com>
Message-ID: <5085F006.1080508@oracle.com>

On 22/10/2012 11:00 PM, Volker Simonis wrote:
> On Mon, Oct 22, 2012 at 1:42 PM, David Holmes<david.holmes at oracle.com>  wrote:
>> On 22/10/2012 5:42 PM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> could you please explain why we need duplicate bug ids in hsx24?
>>
>>
>> The same reason as needed in other hsx version: changesets covering the same
>> bugids can come in from different paths. The fixes are the same bit they are
>> distinct changesets.
>>
>
> Yes, but this is something I don't understand. Why don't you use
> different bug IDs for different changesets?
> Anyway you create new bug IDs for backports and other codelines (those
> starting with 2xxxxxx). So why not using them when checking in such
> 'distinct changesets' into other codelines?

In the past we have only had the primary bug id to use - even for 
backports coming in through different paths. With Jira we do now have 
much more obvious distinct issue numbers for the backports, but the 
process has been re-affirmed to continue to use the primary bug id for 
changesets.

I can't address the "why" aspect of this.

David
-----

> Additionally, it is not always true that  the fixes are "really" the
> same. Sometimes they have to be adapted (e.g. when they are backported
> from the hsx main-line to an older hsxYY stabilization code line).
> Having different bug IDs for such changes would make thinks a lot
> clearer from my point of view.
>
> Regards,
> Volker
>
>>> Apparently this was not necessary for hsx23.
>>
>>
>> I think you will find it is necessary in most of the hsx families.
>>
>> David
>>
>>
>>>
>>> Regards,
>>> Volker
>>>
>>> On Sat, Oct 20, 2012 at 1:39 AM,<alejandro.murillo at oracle.com>   wrote:
>>>>
>>>> Changeset: 81d17d9ab7c9
>>>> Author:    amurillo
>>>> Date:      2012-10-19 16:37 -0700
>>>> URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/81d17d9ab7c9
>>>>
>>>> 8001192: allow duplicate bug ids in hs24
>>>> Reviewed-by: jcoomes
>>>>
>>>> ! .jcheck/conf
>>>>
>>

From keith.mcguigan at oracle.com  Mon Oct 22 19:39:21 2012
From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com)
Date: Tue, 23 Oct 2012 02:39:21 +0000
Subject: hg: hsx/hotspot-main/jdk: 8001225: Disable jdk regression test
	java/lang/System/Versions.java until jdk's classfile version
	code is updated
Message-ID: <20121023023956.E20AF474B9@hg.openjdk.java.net>

Changeset: 7a7e49acadec
Author:    kamg
Date:      2012-10-22 20:12 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7a7e49acadec

8001225: Disable jdk regression test java/lang/System/Versions.java until jdk's classfile version code is updated
Summary: Exclude java/lang/System/Versions.java test
Reviewed-by: sspitsyn, coleenp

! test/ProblemList.txt


From John.Coomes at oracle.com  Mon Oct 22 22:44:19 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Mon, 22 Oct 2012 22:44:19 -0700
Subject: hg: hsx/hsx24/hotspot: 8001192: allow duplicate bug ids in hs24
In-Reply-To: <CA+3eh130XCnG_keCOX12+qbtT1KTyR2Wwt_aVpAR=V_QX+rjgQ@mail.gmail.com>
References: <20121019233937.4043447466@hg.openjdk.java.net>
	<CA+3eh130XCnG_keCOX12+qbtT1KTyR2Wwt_aVpAR=V_QX+rjgQ@mail.gmail.com>
Message-ID: <20614.11955.155982.652398@oracle.com>

Volker Simonis (volker.simonis at gmail.com) wrote:
> Hi,
> 
> could you please explain why we need duplicate bug ids in hsx24?

hsx24 is now being delivered solely into jdk7u (7u12).  It's less
confusing and safest if it's identical to the release into which it's
being delivered, so the changesets from 7u12 were pushed into hsx24.

> Apparently this was not necessary for hsx23.

It wasn't done in hsx23, but was started in hsx23.2 (7u6).

-John

> On Sat, Oct 20, 2012 at 1:39 AM,  <alejandro.murillo at oracle.com> wrote:
> > Changeset: 81d17d9ab7c9
> > Author:    amurillo
> > Date:      2012-10-19 16:37 -0700
> > URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/81d17d9ab7c9
> >
> > 8001192: allow duplicate bug ids in hs24
> > Reviewed-by: jcoomes
> >
> > ! .jcheck/conf
> >

From alejandro.murillo at oracle.com  Tue Oct 23 01:52:10 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 23 Oct 2012 02:52:10 -0600
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <50865ABA.5010104@oracle.com>

Vote: yes

On 10/22/2012 6:14 AM, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From roland.westrelin at oracle.com  Tue Oct 23 02:43:45 2012
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Oct 2012 11:43:45 +0200
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <50865ABA.5010104@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
	<50865ABA.5010104@oracle.com>
Message-ID: <EF150D1B-D4EC-464B-8818-83665B1950D8@oracle.com>

Vote: yes

Roland.

From david.holmes at oracle.com  Tue Oct 23 05:29:11 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 23 Oct 2012 22:29:11 +1000
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <50868D97.7050305@oracle.com>

Vote: yes

David

On 22/10/2012 10:14 PM, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From roland.westrelin at oracle.com  Tue Oct 23 06:20:19 2012
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Oct 2012 15:20:19 +0200
Subject: New HSX Committer: Dean Long
Message-ID: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>

I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.

Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com

Votes are due by Nov 6, 2012.

Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Thanks,
Roland Westrelin

[1] http://openjdk.java.net/projects/#project-committer
[2] http://openjdk.java.net/census#hsx
[3] http://openjdk.java.net/projects#committer-vote

From zhengyu.gu at oracle.com  Tue Oct 23 06:49:01 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 23 Oct 2012 09:49:01 -0400
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5086A04D.2020100@oracle.com>

Vote: yes

-Zhengyu

On 10/23/2012 9:20 AM, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From krystal.mo at oracle.com  Tue Oct 23 06:50:15 2012
From: krystal.mo at oracle.com (Krystal Mo)
Date: Tue, 23 Oct 2012 21:50:15 +0800
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <5086A097.5020809@oracle.com>

Vote: yes

- Kris

On 2012/10/22 20:14, Staffan Larsen wrote:
> I hereby nominate Nils Loodin (OpenJDK user name: nloodin) to HSX Committer.
>
> Nils is a member of the Hotspot/JDK Serviceability group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nils.loodin
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=nloodin
>
> Votes are due by Nov 5, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes
> must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Staffan Larsen
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

From vladimir.danushevsky at oracle.com  Tue Oct 23 07:02:16 2012
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Tue, 23 Oct 2012 10:02:16 -0400
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <2C9747D7-1C13-488E-A1B3-ABA203A79245@oracle.com>

Vote: Yes


On Oct 23, 2012, at 9:20 AM, Roland Westrelin wrote:

> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX  
> Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8  
> changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this  
> nomination.  Votes must be cast in the open by replying to this  
> mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From krystal.mo at oracle.com  Tue Oct 23 07:29:05 2012
From: krystal.mo at oracle.com (Krystal Mo)
Date: Tue, 23 Oct 2012 22:29:05 +0800
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5086A9B1.2020008@oracle.com>

Vote: yes

- Kris

On 2012/10/23 21:20, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From vladimir.kozlov at oracle.com  Tue Oct 23 08:14:20 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Oct 2012 08:14:20 -0700
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <B28EABA3-8C3E-4948-87D8-4EF62C9ABE4D@oracle.com>

Vote: yes

On Oct 23, 2012, at 6:20 AM, Roland Westrelin wrote:

> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
> 
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
> 
> Votes are due by Nov 6, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Roland Westrelin
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From daniel.daugherty at oracle.com  Tue Oct 23 08:17:24 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 23 Oct 2012 09:17:24 -0600
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5086B504.9010404@oracle.com>

Vote: yes

Dan


On 10/23/12 7:20 AM, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From karen.kinnear at oracle.com  Tue Oct 23 08:23:04 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 23 Oct 2012 11:23:04 -0400
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <BAF0EC37-CBF0-4FAC-AC7E-6006724FEF2F@oracle.com>

Vote: yes

thanks,
Karen

On Oct 23, 2012, at 9:20 AM, Roland Westrelin wrote:

> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
> 
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
> 
> Votes are due by Nov 6, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Roland Westrelin
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From coleen.phillimore at oracle.com  Tue Oct 23 08:28:29 2012
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Tue, 23 Oct 2012 11:28:29 -0400
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5086B79D.1010304@oracle.com>

Vote: yes

On 10/23/2012 9:20 AM, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From bob.vandette at oracle.com  Tue Oct 23 08:30:40 2012
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 23 Oct 2012 11:30:40 -0400
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <C24F348C-48B4-4F6E-BFC8-4586DEE1C810@oracle.com>

Vote:  Yes

Bob Vandette


On Oct 23, 2012, at 9:20 AM, Roland Westrelin wrote:

> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
> 
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
> 
> Votes are due by Nov 6, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Roland Westrelin
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From bertrand.delsart at oracle.com  Tue Oct 23 08:42:45 2012
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Tue, 23 Oct 2012 17:42:45 +0200
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5086BAF5.2050300@oracle.com>

Vote: yes

Bertrand.

Le 23/10/2012 15:20, Roland Westrelin a ?crit :
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>


From jiangli.zhou at oracle.com  Tue Oct 23 09:12:46 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 23 Oct 2012 09:12:46 -0700
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5086C1FE.1090607@oracle.com>

Vote: yes

Jiangli

On 10/23/2012 06:20 AM, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From ysr1729 at gmail.com  Tue Oct 23 09:24:49 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Tue, 23 Oct 2012 09:24:49 -0700
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <CABzyjynnC_EJXMfYaoY4_cmUd6PitnzNLP037xb7mKOtdxi=jA@mail.gmail.com>

Vote: yes

-- ramki (openjdk: ysr)

On Tue, Oct 23, 2012 at 6:20 AM, Roland Westrelin <
roland.westrelin at oracle.com> wrote:

> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8
> changesets to the HSX project and he is qualified to be committer [1]:
>
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.
>  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From christian.thalinger at oracle.com  Tue Oct 23 09:31:34 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Oct 2012 09:31:34 -0700
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <DC32F21E-1EFA-4E79-A1A3-40276AE60AC0@oracle.com>

Vote: yes

On Oct 23, 2012, at 6:20 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
> 
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
> 
> Votes are due by Nov 6, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Roland Westrelin
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From aph at redhat.com  Tue Oct 23 09:47:40 2012
From: aph at redhat.com (Andrew Haley)
Date: Tue, 23 Oct 2012 17:47:40 +0100
Subject: We're doing an ARM64 port
Message-ID: <5086CA2C.6070600@redhat.com>

FYI, if you haven't heard about this already, we at Red Hat
are doing an ARM64 HotSpot port.  We intend to submit this an an
OpenJDK project.

The full article is at http://www.advogato.org/article/1067.html.

Andrew.

From volker.simonis at gmail.com  Tue Oct 23 09:58:50 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 23 Oct 2012 18:58:50 +0200
Subject: We're doing an ARM64 port
In-Reply-To: <5086CA2C.6070600@redhat.com>
References: <5086CA2C.6070600@redhat.com>
Message-ID: <CA+3eh13svd20XfWnP1pFAJYTJ+jXA2H=SbKi2H0mVPk8U-ycGw@mail.gmail.com>

Hi Andrew,

great to hear this project being "officially announced"!

Wish you all the best and looking forward seeing the real code:)

Volker


On Tue, Oct 23, 2012 at 6:47 PM, Andrew Haley <aph at redhat.com> wrote:
> FYI, if you haven't heard about this already, we at Red Hat
> are doing an ARM64 HotSpot port.  We intend to submit this an an
> OpenJDK project.
>
> The full article is at http://www.advogato.org/article/1067.html.
>
> Andrew.

From bob.vandette at oracle.com  Tue Oct 23 09:59:21 2012
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 23 Oct 2012 12:59:21 -0400
Subject: We're doing an ARM64 port
In-Reply-To: <5086CA2C.6070600@redhat.com>
References: <5086CA2C.6070600@redhat.com>
Message-ID: <3FB74F06-4E18-47EA-9173-FE0183B195B0@oracle.com>

Is this going to be C2 server compiler based?

Bob


On Oct 23, 2012, at 12:47 PM, Andrew Haley wrote:

> FYI, if you haven't heard about this already, we at Red Hat
> are doing an ARM64 HotSpot port.  We intend to submit this an an
> OpenJDK project.
> 
> The full article is at http://www.advogato.org/article/1067.html.
> 
> Andrew.


From aph at redhat.com  Tue Oct 23 10:02:34 2012
From: aph at redhat.com (Andrew Haley)
Date: Tue, 23 Oct 2012 18:02:34 +0100
Subject: We're doing an ARM64 port
In-Reply-To: <3FB74F06-4E18-47EA-9173-FE0183B195B0@oracle.com>
References: <5086CA2C.6070600@redhat.com>
	<3FB74F06-4E18-47EA-9173-FE0183B195B0@oracle.com>
Message-ID: <5086CDAA.9040808@redhat.com>

On 10/23/2012 05:59 PM, Bob Vandette wrote:
> Is this going to be C2 server compiler based?

"After some thought we've decided to write C1 (the client JIT) first
and then proceed to C2 (the server JIT)"

Andrew.

From bengt.rutisson at oracle.com  Tue Oct 23 12:15:06 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 23 Oct 2012 21:15:06 +0200
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5086ECBA.4010003@oracle.com>


Vote: yes

Bengt

On 2012-10-23 15:20, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From John.Coomes at oracle.com  Tue Oct 23 16:08:38 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Tue, 23 Oct 2012 16:08:38 -0700
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <20615.9078.734624.879954@oracle.com>

Vote: yes

-John


From John.Coomes at oracle.com  Tue Oct 23 16:10:36 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Tue, 23 Oct 2012 16:10:36 -0700
Subject: CFV: New HSX Committer: Nils Loodin
In-Reply-To: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
References: <8B3523F2-4237-4C11-8D11-0C02361C14D6@oracle.com>
Message-ID: <20615.9196.761844.79820@oracle.com>

Vote: yes

-John

From john.r.rose at oracle.com  Tue Oct 23 16:39:54 2012
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 23 Oct 2012 16:39:54 -0700
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <6564BDE4-38D3-4394-87FC-742A6ECCC164@oracle.com>

Vote: yes

From tmarble at info9.net  Tue Oct 23 16:50:13 2012
From: tmarble at info9.net (Tom Marble)
Date: Tue, 23 Oct 2012 18:50:13 -0500
Subject: We're doing an ARM64 port
In-Reply-To: <5086CA2C.6070600@redhat.com>
References: <5086CA2C.6070600@redhat.com>
Message-ID: <50872D35.2000104@info9.net>

On 10/23/2012 11:47 AM, Andrew Haley wrote:
> FYI, if you haven't heard about this already, we at Red Hat
> are doing an ARM64 HotSpot port.  We intend to submit this an an
> OpenJDK project.

This is fantastic news! Thank you Red Hat and thank you Andrew
for leading this effort that you got us dreaming about at your
FOSDEM talk [0].

This decision is very significant because:

- Now is the time to invest in ARMv8: hopefully we'll have
  simulators soon, silicon sometime next year and systems
  soon thereafter.

- Java succeeding on this platform (different architecture)
  will require a serious engineering effort into HotSpot.
  This investment will pay off directly for Java applications
  and for the amazing languages built on top of the JVM
  such as JRuby and Clojure.

- Both environmentalists and savvy customers will prefer
  the energy saving systems made possible by ARMv8. Enabling
  applications that run on Java / Linux / ARMv8 will be
  critical to driving competition in "green" computing.

- Oracle has signaled lack of willingness to contribute ARM
  work to OpenJDK

It's a shame that Java's ubiquity has suffered due to Oracle's
choice of withholding certain features from OpenJDK (e.g. the new
plugin) combined with the withdrawal of the DLJ bundles which
allowed Operating System distributions to package and redistribute
Java (albeit under a non-free license).

Having a technically strong, Free Software Java HotSpot implementation
on this important deployment target should forestall further
Java platform fragmentation.

Indeed it is in Oracle's business interest for Java to be strong
everywhere -- including on all of their current and future hardware --
so I hope that this new port will be warmly received.

Sincerely,

--Tom

[0] https://archive.fosdem.org/2012/schedule/event/openjdk_on_arm.html

From david.holmes at oracle.com  Tue Oct 23 21:35:48 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 Oct 2012 14:35:48 +1000
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <50877024.2020305@oracle.com>

Vote: yes

David

On 23/10/2012 11:20 PM, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From staffan.larsen at oracle.com  Wed Oct 24 00:13:54 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 24 Oct 2012 09:13:54 +0200
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <C3C20D7D-5EED-44E0-BBF6-D8E5FBD83A5A@oracle.com>

Vote: yes.

/Staffan

On 23 okt 2012, at 15:20, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
> 
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
> 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
> 
> Votes are due by Nov 6, 2012.
> 
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Thanks,
> Roland Westrelin
> 
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From adinn at redhat.com  Wed Oct 24 00:44:09 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 24 Oct 2012 08:44:09 +0100
Subject: We're doing an ARM64 port
In-Reply-To: <50872D35.2000104@info9.net>
References: <5086CA2C.6070600@redhat.com> <50872D35.2000104@info9.net>
Message-ID: <50879C49.4070300@redhat.com>

On 24/10/12 00:50, Tom Marble wrote:
>   . . . hopefully we'll have
>   simulators soon, silicon sometime next year and systems
>   soon thereafter.

As Andrew mentioned in the blog post we are exercising our generated
ARMv8 code on a functional simulator. When we get the go-ahead from ARM
to publish our code (precise details of the architecture were given to
us under NDA about 4 months ago so we need a nod from them) this should
be something others can re-use.

regards,


Andrew Dinn
-----------


From kevin.walls at oracle.com  Wed Oct 24 03:34:46 2012
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 24 Oct 2012 11:34:46 +0100
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5087C446.2030108@oracle.com>

Vote: yes

From frederic.parain at oracle.com  Wed Oct 24 05:35:37 2012
From: frederic.parain at oracle.com (Frederic Parain)
Date: Wed, 24 Oct 2012 14:35:37 +0200
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <5087E099.4000007@oracle.com>

Vote: yes

Fred

On 10/23/12 03:20 PM, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at Oracle.com


From alejandro.murillo at oracle.com  Wed Oct 24 11:59:50 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 24 Oct 2012 12:59:50 -0600
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <50883AA6.3070106@oracle.com>

vote: yes

On 10/23/2012 7:20 AM, Roland Westrelin wrote:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote

From nils.eliasson at oracle.com  Wed Oct 24 12:18:59 2012
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 24 Oct 2012 21:18:59 +0200
Subject: New HSX Committer: Dean Long
In-Reply-To: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
References: <60744A1D-BE43-4C35-A047-B50D3D7B12F3@oracle.com>
Message-ID: <50883F23.8090109@oracle.com>

vote: yes

Roland Westrelin skrev 2012-10-23 15:20:
> I hereby nominate Dean Long (OpenJDK user name: dlong) to HSX Committer.
>
> Dean is a member of the Hotspot embedded group. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=dean.long at oracle.com
>
> Votes are due by Nov 6, 2012.
>
> Only current HSX Committers [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Thanks,
> Roland Westrelin
>
> [1] http://openjdk.java.net/projects/#project-committer
> [2] http://openjdk.java.net/census#hsx
> [3] http://openjdk.java.net/projects#committer-vote


From vladimir.kozlov at oracle.com  Thu Oct 25 07:22:16 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Oct 2012 07:22:16 -0700
Subject: Result: New HSX Committer: Vladimir Ivanov
Message-ID: <406C03C1-E65E-459E-B68C-BB7862977E7A@oracle.com>

Voting for Vladimir Ivanov [1] is now closed.

Yes: 15
Veto: 0
Abstain: 0

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

Vladimir Kozlov

[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/006817.html
[2] http://openjdk.java.net/bylaws#lazy-consensus


From jiangli.zhou at oracle.com  Thu Oct 25 16:14:41 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 25 Oct 2012 16:14:41 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
Message-ID: <5089C7E1.2040206@oracle.com>

Hi,

Please review the timeout change to 
test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes 
longer time to execute on certain embedded devices. It takes about 23 
minutes to run on an ARM softfloat device with fastdebug binary. Using a 
2000s timeout here just to be sure.

   http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/

Thanks,
Jiangli


From christian.thalinger at oracle.com  Thu Oct 25 16:53:11 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 25 Oct 2012 16:53:11 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java
	failing on armsflt
In-Reply-To: <5089C7E1.2040206@oracle.com>
References: <5089C7E1.2040206@oracle.com>
Message-ID: <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com>


On Oct 25, 2012, at 4:14 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi,
> 
> Please review the timeout change to test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes longer time to execute on certain embedded devices. It takes about 23 minutes to run on an ARM softfloat device with fastdebug binary. Using a 2000s timeout here just to be sure.
> 
>  http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/

java/lang/invoke/MethodHandlesTest.java does not timeout?

-- Chris

> 
> Thanks,
> Jiangli
> 


From jiangli.zhou at oracle.com  Thu Oct 25 17:18:24 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 25 Oct 2012 17:18:24 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com>
References: <5089C7E1.2040206@oracle.com>
	<7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com>
Message-ID: <5089D6D0.3070909@oracle.com>

Hi Chris,

java/lang/invoke/MethodHandlesTest.java times out on all ARM devices in 
nightly testing. Need to verify if the test can run to completion on ARM 
and determine the proper timeout value. Will handle that separately.

Thanks,
Jiangli

On 10/25/2012 4:53 PM, Christian Thalinger wrote:
> On Oct 25, 2012, at 4:14 PM, Jiangli Zhou<jiangli.zhou at oracle.com>  wrote:
>
>> Hi,
>>
>> Please review the timeout change to test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes longer time to execute on certain embedded devices. It takes about 23 minutes to run on an ARM softfloat device with fastdebug binary. Using a 2000s timeout here just to be sure.
>>
>>   http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
> java/lang/invoke/MethodHandlesTest.java does not timeout?
>
> -- Chris
>
>> Thanks,
>> Jiangli
>>

From christian.thalinger at oracle.com  Thu Oct 25 17:35:43 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 25 Oct 2012 17:35:43 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java
	failing on armsflt
In-Reply-To: <5089D6D0.3070909@oracle.com>
References: <5089C7E1.2040206@oracle.com>
	<7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com>
	<5089D6D0.3070909@oracle.com>
Message-ID: <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com>

We also have timeouts in our nightly testing with fastdebug builds on older SPARC hardware.  I couldn't decide yet what the right fix is (decrease workload, increase timeout).

There are two other tests that could potentially timeout:

java/lang/invoke/RicochetTest.java
java/lang/invoke/PermuteArgsTest.java

I fixed the latter with:

http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/59231f2cb6e1

Is PermuteArgsTest good on ARM?

-- Chris

On Oct 25, 2012, at 5:18 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi Chris,
> 
> java/lang/invoke/MethodHandlesTest.java times out on all ARM devices in nightly testing. Need to verify if the test can run to completion on ARM and determine the proper timeout value. Will handle that separately.
> 
> Thanks,
> Jiangli
> 
> On 10/25/2012 4:53 PM, Christian Thalinger wrote:
>> On Oct 25, 2012, at 4:14 PM, Jiangli Zhou<jiangli.zhou at oracle.com>  wrote:
>> 
>>> Hi,
>>> 
>>> Please review the timeout change to test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes longer time to execute on certain embedded devices. It takes about 23 minutes to run on an ARM softfloat device with fastdebug binary. Using a 2000s timeout here just to be sure.
>>> 
>>>  http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
>> java/lang/invoke/MethodHandlesTest.java does not timeout?
>> 
>> -- Chris
>> 
>>> Thanks,
>>> Jiangli
>>> 


From jiangli.zhou at oracle.com  Thu Oct 25 18:09:42 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 25 Oct 2012 18:09:42 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com>
References: <5089C7E1.2040206@oracle.com>
	<7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com>
	<5089D6D0.3070909@oracle.com>
	<5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com>
Message-ID: <5089E2D6.8050707@oracle.com>

Hi Chris,

I see following tests have timeout on ARM devices. But they are not 
consistent. The BigArityTest.java and RicochetTest.java sometimes can 
complete without problem. I haven't noticed issue with PermuteArgsTest.java.

BigArityTest.java
CallSiteTest.java
MethodHandlesTest.java
RicochetTest.java

Thanks,
Jiangli


On 10/25/2012 5:35 PM, Christian Thalinger wrote:
> We also have timeouts in our nightly testing with fastdebug builds on older SPARC hardware.  I couldn't decide yet what the right fix is (decrease workload, increase timeout).
>
> There are two other tests that could potentially timeout:
>
> java/lang/invoke/RicochetTest.java
> java/lang/invoke/PermuteArgsTest.java
>
> I fixed the latter with:
>
> http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/59231f2cb6e1
>
> Is PermuteArgsTest good on ARM?
>
> -- Chris
>
> On Oct 25, 2012, at 5:18 PM, Jiangli Zhou<jiangli.zhou at oracle.com>  wrote:
>
>> Hi Chris,
>>
>> java/lang/invoke/MethodHandlesTest.java times out on all ARM devices in nightly testing. Need to verify if the test can run to completion on ARM and determine the proper timeout value. Will handle that separately.
>>
>> Thanks,
>> Jiangli
>>
>> On 10/25/2012 4:53 PM, Christian Thalinger wrote:
>>> On Oct 25, 2012, at 4:14 PM, Jiangli Zhou<jiangli.zhou at oracle.com>   wrote:
>>>
>>>> Hi,
>>>>
>>>> Please review the timeout change to test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes longer time to execute on certain embedded devices. It takes about 23 minutes to run on an ARM softfloat device with fastdebug binary. Using a 2000s timeout here just to be sure.
>>>>
>>>>   http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
>>> java/lang/invoke/MethodHandlesTest.java does not timeout?
>>>
>>> -- Chris
>>>
>>>> Thanks,
>>>> Jiangli
>>>>

From kelly.ohair at oracle.com  Thu Oct 25 18:24:41 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 25 Oct 2012 18:24:41 -0700
Subject: Request for Review: Add hotspot support for building with
	mingw/msys on build-infra (the new build)
In-Reply-To: <50894371.5010001@oracle.com>
References: <50894371.5010001@oracle.com>
Message-ID: <08803191-4297-4464-B062-0F7010585D5F@oracle.com>

It has been my experience that using cygpath -w created problems with shell escape logic,
and that is why cygpath -m with a make level subst change is done, it was less problematic.

I don't understand why you would even want to change the cygwin logic at all, if it isn't broken why mess with it?

So my suggestion would be to add the msys logic, and leave the old cygwin logic alone.

I could have sworn that Tim Bell already did this change, and yes, if I look at:

    http://hg.openjdk.java.net/jdk8/build/hotspot/file/dccd40de8db1/make/windows/makefiles/defs.make

These changes are there already, or something equivalent.

Have you talked with Tim Bell about this change?

-kto

On Oct 25, 2012, at 6:49 AM, Magnus Ihse Bursie wrote:

> The following patch will allow build-infra to perform builds on MinGW/MSys.
> 
> It also updates the case for cygwin, with the two changes:
> 
> 1) It replaces a $(subst) from / to \ which acted on output from cygpath -m (mixed mode), with just cygpath -w (windows mode, i.e. mixed mode but with \ instead of /).
> 
> 2) In analogy with the msys case, we only do path convertion of the first word (i.e. the executable), not any possibly following arguments. In reality, there are no argument in the cygwin case (in contrary to the msys case, where the build infra solution requires passing additional arguments to the binaries).
> 
> If these are problematic, they can be dropped. The important part, from build-infras point of view, is the mingw case.
> 
> http://cr.openjdk.java.net/~ihse/hotspot-build-infra-msys-support/webrev.00/
> 
> /Magnus


From gary.collins at oracle.com  Thu Oct 25 20:28:26 2012
From: gary.collins at oracle.com (Gary Collins)
Date: Thu, 25 Oct 2012 20:28:26 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java
	failing on armsflt
In-Reply-To: <5089E2D6.8050707@oracle.com>
References: <5089C7E1.2040206@oracle.com>
	<7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com>
	<5089D6D0.3070909@oracle.com>
	<5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com>
	<5089E2D6.8050707@oracle.com>
Message-ID: <B152F5B0-6D03-427D-8E15-FA68B9471F12@oracle.com>

I have another test to add timeout and UsePerfData as well. Maybe we should just make all these at same time.  Mine is in hotspot test dir




On Oct 25, 2012, at 6:09 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi Chris,
> 
> I see following tests have timeout on ARM devices. But they are not consistent. The BigArityTest.java and RicochetTest.java sometimes can complete without problem. I haven't noticed issue with PermuteArgsTest.java.
> 
> BigArityTest.java
> CallSiteTest.java
> MethodHandlesTest.java
> RicochetTest.java
> 
> Thanks,
> Jiangli
> 
> 
> On 10/25/2012 5:35 PM, Christian Thalinger wrote:
>> We also have timeouts in our nightly testing with fastdebug builds on older SPARC hardware.  I couldn't decide yet what the right fix is (decrease workload, increase timeout).
>> 
>> There are two other tests that could potentially timeout:
>> 
>> java/lang/invoke/RicochetTest.java
>> java/lang/invoke/PermuteArgsTest.java
>> 
>> I fixed the latter with:
>> 
>> http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/59231f2cb6e1
>> 
>> Is PermuteArgsTest good on ARM?
>> 
>> -- Chris
>> 
>> On Oct 25, 2012, at 5:18 PM, Jiangli Zhou<jiangli.zhou at oracle.com>  wrote:
>> 
>>> Hi Chris,
>>> 
>>> java/lang/invoke/MethodHandlesTest.java times out on all ARM devices in nightly testing. Need to verify if the test can run to completion on ARM and determine the proper timeout value. Will handle that separately.
>>> 
>>> Thanks,
>>> Jiangli
>>> 
>>> On 10/25/2012 4:53 PM, Christian Thalinger wrote:
>>>> On Oct 25, 2012, at 4:14 PM, Jiangli Zhou<jiangli.zhou at oracle.com>   wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Please review the timeout change to test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes longer time to execute on certain embedded devices. It takes about 23 minutes to run on an ARM softfloat device with fastdebug binary. Using a 2000s timeout here just to be sure.
>>>>> 
>>>>>  http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
>>>> java/lang/invoke/MethodHandlesTest.java does not timeout?
>>>> 
>>>> -- Chris
>>>> 
>>>>> Thanks,
>>>>> Jiangli
>>>>> 

From john.coomes at oracle.com  Thu Oct 25 20:31:40 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Oct 2012 03:31:40 +0000
Subject: hg: hsx/hotspot-main: 3 new changesets
Message-ID: <20121026033140.92F2C47560@hg.openjdk.java.net>

Changeset: c12e759ac4e8
Author:    tbell
Date:      2012-10-23 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/c12e759ac4e8

7152336: Enable builds on Windows with MinGW/MSYS
Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7
Reviewed-by: ohair, tbell
Contributed-by: volker.simonis at gmail.com

! README-builds.html
+ make/scripts/fixpath.pl
! make/scripts/vsvars.sh

Changeset: 8a3fe0ae06a8
Author:    katleman
Date:      2012-10-24 13:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/8a3fe0ae06a8

Merge


Changeset: 4e984be114bd
Author:    katleman
Date:      2012-10-25 09:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/4e984be114bd

Added tag jdk8-b62 for changeset 8a3fe0ae06a8

! .hgtags


From john.coomes at oracle.com  Thu Oct 25 20:31:44 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Oct 2012 03:31:44 +0000
Subject: hg: hsx/hotspot-main/corba: 3 new changesets
Message-ID: <20121026033148.C600947561@hg.openjdk.java.net>

Changeset: 0a5931be9176
Author:    tbell
Date:      2012-10-23 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0a5931be9176

7152336: Enable builds on Windows with MinGW/MSYS
Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7
Reviewed-by: ohair, tbell
Contributed-by: volker.simonis at gmail.com

! make/common/shared/Defs-utils.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Platform.gmk

Changeset: 08afb9c6f44f
Author:    katleman
Date:      2012-10-24 13:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/08afb9c6f44f

Merge


Changeset: bbaef650c3d2
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/bbaef650c3d2

Added tag jdk8-b62 for changeset 08afb9c6f44f

! .hgtags


From john.coomes at oracle.com  Thu Oct 25 20:31:52 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Oct 2012 03:31:52 +0000
Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b62 for changeset
	5d0fa0108d02
Message-ID: <20121026033203.9546547562@hg.openjdk.java.net>

Changeset: a96e34e038f5
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a96e34e038f5

Added tag jdk8-b62 for changeset 5d0fa0108d02

! .hgtags


From john.coomes at oracle.com  Thu Oct 25 20:32:07 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Oct 2012 03:32:07 +0000
Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b62 for changeset
	d265b9b4c0f5
Message-ID: <20121026033213.31D4247563@hg.openjdk.java.net>

Changeset: c27ea8d489e8
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c27ea8d489e8

Added tag jdk8-b62 for changeset d265b9b4c0f5

! .hgtags


From john.coomes at oracle.com  Thu Oct 25 20:32:22 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Oct 2012 03:32:22 +0000
Subject: hg: hsx/hotspot-main/jdk: 3 new changesets
Message-ID: <20121026033320.5807E47564@hg.openjdk.java.net>

Changeset: a0a2b186ae28
Author:    tbell
Date:      2012-10-23 10:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a0a2b186ae28

7152336: Enable builds on Windows with MinGW/MSYS
Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7
Reviewed-by: ohair, tbell
Contributed-by: volker.simonis at gmail.com

! make/com/sun/java/pack/Makefile
! make/common/Defs-windows.gmk
! make/common/Demo.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/Release.gmk
! make/common/shared/Defs-utils.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Platform.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/jdk_generic_profile.sh
! make/tools/freetypecheck/Makefile
+ make/tools/msys_build_scripts/dospath.sh
+ make/tools/msys_build_scripts/dospath.vbs

Changeset: 50b8b17449d2
Author:    katleman
Date:      2012-10-24 13:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/50b8b17449d2

Merge


Changeset: 65d2c6726487
Author:    katleman
Date:      2012-10-25 09:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/65d2c6726487

Added tag jdk8-b62 for changeset 50b8b17449d2

! .hgtags


From john.coomes at oracle.com  Thu Oct 25 20:34:16 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Oct 2012 03:34:16 +0000
Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b62 for changeset
	b47bb81ba962
Message-ID: <20121026033424.119A247565@hg.openjdk.java.net>

Changeset: 16498acd21b5
Author:    katleman
Date:      2012-10-25 09:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/16498acd21b5

Added tag jdk8-b62 for changeset b47bb81ba962

! .hgtags


From Alan.Bateman at oracle.com  Fri Oct 26 01:41:56 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Oct 2012 09:41:56 +0100
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <5089C7E1.2040206@oracle.com>
References: <5089C7E1.2040206@oracle.com>
Message-ID: <508A4CD4.2090009@oracle.com>

On 26/10/2012 00:14, Jiangli Zhou wrote:
> Hi,
>
> Please review the timeout change to 
> test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes 
> longer time to execute on certain embedded devices. It takes about 23 
> minutes to run on an ARM softfloat device with fastdebug binary. Using 
> a 2000s timeout here just to be sure.
>
>   http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
>
> Thanks,
> Jiangli
>
You might know this already but the jtreg -timeoutFactor option can be 
used to apply a scaling factor to the timeout. This may not be fine 
grained enough to only increase it for tests that are floating point 
intensive but it is generally useful to use this when running tests on 
slow machines. The downside is that it increases the overall execution 
time when there are tests that fail due to reaching the timeout (but 
such tests could be added to the exclude list to avoid running them).

-Alan

From staffan.larsen at oracle.com  Fri Oct 26 03:47:35 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 26 Oct 2012 12:47:35 +0200
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
Message-ID: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>

This is an attempt at cleaning up the source in src/os/bsd by removing the usage of _ALLBSD_SOURCE in these files. Since the define is always set when compiling these files it is not necessary to use it in the source files. The usage was originally added during the porting to make it easier to see changes against the base linux version.

http://cr.openjdk.java.net/~sla/8001619/webrev.00/

Thanks,
/Staffan

From david.holmes at oracle.com  Fri Oct 26 04:35:46 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Oct 2012 21:35:46 +1000
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
Message-ID: <508A7592.4070800@oracle.com>

On 26/10/2012 8:47 PM, Staffan Larsen wrote:
> This is an attempt at cleaning up the source in src/os/bsd by removing the usage of _ALLBSD_SOURCE in these files. Since the define is always set when compiling these files it is not necessary to use it in the source files. The usage was originally added during the porting to make it easier to see changes against the base linux version.
>
> http://cr.openjdk.java.net/~sla/8001619/webrev.00/

Generally looks okay (though now I see some of the actual BSD code it 
makes me a little nervous!). A couple of minor things:

os_bsd.cpp:

977 }
978 #elif

3957   return true;
3958 #elif
3959   return false;

Shouldn't the elif's have become an else?

Ditto for os_bsd_x86.cpp:

850 #elif

Also you can probably do the same thing for bsd_zero: 
/src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.

David
-----

> Thanks,
> /Staffan

From coleen.phillimore at oracle.com  Fri Oct 26 04:37:09 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 26 Oct 2012 07:37:09 -0400
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
Message-ID: <508A75E5.2070100@oracle.com>

Staffan,   This looks really good.

Can you change the conditional now in arguments.cpp?   Harold's checked 
in that change yesterday.   Didn't know you'd get to this so fast. :)   
I guess it should be __APPLE__ now (idk).

A prize should go to someone who comes up with a better name for the 
posix directory and we should add common code there. Although it looks 
like os_bsd.cpp doesn't share as much with os_linux.cpp as hoped.  I 
think we can't use 'unix'.    How about 'ix'?

Thanks,
Coleen

On 10/26/2012 6:47 AM, Staffan Larsen wrote:
> This is an attempt at cleaning up the source in src/os/bsd by removing the usage of _ALLBSD_SOURCE in these files. Since the define is always set when compiling these files it is not necessary to use it in the source files. The usage was originally added during the porting to make it easier to see changes against the base linux version.
>
> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>
> Thanks,
> /Staffan


From staffan.larsen at oracle.com  Fri Oct 26 04:58:46 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 26 Oct 2012 13:58:46 +0200
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508A7592.4070800@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
Message-ID: <9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>


On 26 okt 2012, at 13:35, David Holmes <David.Holmes at oracle.com> wrote:

> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>> This is an attempt at cleaning up the source in src/os/bsd by removing the usage of _ALLBSD_SOURCE in these files. Since the define is always set when compiling these files it is not necessary to use it in the source files. The usage was originally added during the porting to make it easier to see changes against the base linux version.
>> 
>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
> 
> Generally looks okay (though now I see some of the actual BSD code it makes me a little nervous!). A couple of minor things:

Thanks.

> 
> os_bsd.cpp:
> 
> 977 }
> 978 #elif
> 
> 3957   return true;
> 3958 #elif
> 3959   return false;
> 
> Shouldn't the elif's have become an else?
> 
> Ditto for os_bsd_x86.cpp:
> 
> 850 #elif

You are right. I've fixed this.

> Also you can probably do the same thing for bsd_zero: /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.

I didn't touch the zero files since I wasn't sure who maintains it. I'm not sure how to build it so I didn't want to do changes.

/Staffan


> 
> David
> -----
> 
>> Thanks,
>> /Staffan


From staffan.larsen at oracle.com  Fri Oct 26 05:00:56 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 26 Oct 2012 14:00:56 +0200
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508A75E5.2070100@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A75E5.2070100@oracle.com>
Message-ID: <74CBB3F4-8707-4493-BAA7-9D22BEC9E2E4@oracle.com>


On 26 okt 2012, at 13:37, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> Staffan,   This looks really good.

Thanks.

> 
> Can you change the conditional now in arguments.cpp?   Harold's checked in that change yesterday.   Didn't know you'd get to this so fast. :)   I guess it should be __APPLE__ now (idk).

I think it should still be _ALLBSD_SOURCE since the UseLargePages-issue is true for the src/os/bsd files, not just when compiled with __APPLE__.

/Staffan

> 
> A prize should go to someone who comes up with a better name for the posix directory and we should add common code there. Although it looks like os_bsd.cpp doesn't share as much with os_linux.cpp as hoped.  I think we can't use 'unix'.    How about 'ix'?
> 
> Thanks,
> Coleen
> 
> On 10/26/2012 6:47 AM, Staffan Larsen wrote:
>> This is an attempt at cleaning up the source in src/os/bsd by removing the usage of _ALLBSD_SOURCE in these files. Since the define is always set when compiling these files it is not necessary to use it in the source files. The usage was originally added during the porting to make it easier to see changes against the base linux version.
>> 
>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>> 
>> Thanks,
>> /Staffan
> 


From staffan.larsen at oracle.com  Fri Oct 26 05:03:50 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 26 Oct 2012 14:03:50 +0200
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
Message-ID: <D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>

Oh... and new webrev at: http://cr.openjdk.java.net/~sla/8001619/webrev.01/


On 26 okt 2012, at 13:58, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> 
> On 26 okt 2012, at 13:35, David Holmes <David.Holmes at oracle.com> wrote:
> 
>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>> This is an attempt at cleaning up the source in src/os/bsd by removing the usage of _ALLBSD_SOURCE in these files. Since the define is always set when compiling these files it is not necessary to use it in the source files. The usage was originally added during the porting to make it easier to see changes against the base linux version.
>>> 
>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>> 
>> Generally looks okay (though now I see some of the actual BSD code it makes me a little nervous!). A couple of minor things:
> 
> Thanks.
> 
>> 
>> os_bsd.cpp:
>> 
>> 977 }
>> 978 #elif
>> 
>> 3957   return true;
>> 3958 #elif
>> 3959   return false;
>> 
>> Shouldn't the elif's have become an else?
>> 
>> Ditto for os_bsd_x86.cpp:
>> 
>> 850 #elif
> 
> You are right. I've fixed this.
> 
>> Also you can probably do the same thing for bsd_zero: /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.
> 
> I didn't touch the zero files since I wasn't sure who maintains it. I'm not sure how to build it so I didn't want to do changes.
> 
> /Staffan
> 
> 
>> 
>> David
>> -----
>> 
>>> Thanks,
>>> /Staffan
> 


From coleen.phillimore at oracle.com  Fri Oct 26 05:05:02 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 26 Oct 2012 08:05:02 -0400
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <74CBB3F4-8707-4493-BAA7-9D22BEC9E2E4@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A75E5.2070100@oracle.com>
	<74CBB3F4-8707-4493-BAA7-9D22BEC9E2E4@oracle.com>
Message-ID: <508A7C6E.7080802@oracle.com>

On 10/26/2012 8:00 AM, Staffan Larsen wrote:
> On 26 okt 2012, at 13:37, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> Staffan,   This looks really good.
> Thanks.
>
>> Can you change the conditional now in arguments.cpp?   Harold's checked in that change yesterday.   Didn't know you'd get to this so fast. :)   I guess it should be __APPLE__ now (idk).
> I think it should still be _ALLBSD_SOURCE since the UseLargePages-issue is true for the src/os/bsd files, not just when compiled with __APPLE__.

Ok.
thanks,
Coleen
>
> /Staffan
>
>> A prize should go to someone who comes up with a better name for the posix directory and we should add common code there. Although it looks like os_bsd.cpp doesn't share as much with os_linux.cpp as hoped.  I think we can't use 'unix'.    How about 'ix'?
>>
>> Thanks,
>> Coleen
>>
>> On 10/26/2012 6:47 AM, Staffan Larsen wrote:
>>> This is an attempt at cleaning up the source in src/os/bsd by removing the usage of _ALLBSD_SOURCE in these files. Since the define is always set when compiling these files it is not necessary to use it in the source files. The usage was originally added during the porting to make it easier to see changes against the base linux version.
>>>
>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>
>>> Thanks,
>>> /Staffan


From coleen.phillimore at oracle.com  Fri Oct 26 06:57:26 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 26 Oct 2012 09:57:26 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <5075AC78.3030702@oracle.com>
References: <5075AC78.3030702@oracle.com>
Message-ID: <508A96C6.1080207@oracle.com>


Hi,
I have read through all of this code.  Offline to Keith, I have 
suggested some name changes and comments to make it clearer, at least to 
me, what this code is doing.  It's very dense but I believe it is 
correct and finds the correct default method to add to the vtable in the 
most efficient way possible.
Keith, can you elaborate on the tests that you've run against this?
Thanks,
Coleen

On 10/10/2012 1:12 PM, Keith McGuigan wrote:
> Hello,
>
> I'd like any review of the code which implements default methods in 
> the JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and 
> tracked by CR 7200776.
>
> The design and implementation is described in this short document:
> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>
> And the code is here:
> http://cr.openjdk.java.net/~kamg/default_methods/
>
> Any review (even partial) would be appreciated.  Thanks!
>
> -- 
> - Keith

From keith.mcguigan at oracle.com  Fri Oct 26 07:19:53 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Fri, 26 Oct 2012 10:19:53 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <508A96C6.1080207@oracle.com>
References: <5075AC78.3030702@oracle.com> <508A96C6.1080207@oracle.com>
Message-ID: <B59E913B-F77E-45DF-94FC-4C0F7E02E2AA@oracle.com>


Sure.  In addition to running the internal UTE/JCK tests, the same code has gone through testing as part of the lambda repositories.  There is new test-ng lambda tests in lambda/jdk/test-ng and lambda/jdk/combo-tests (run with ant).  And the entire lambda build (including the new VM bits) gets nightly testing that runs (at least) the workspace regression tests.

--
- Keith

On Oct 26, 2012, at 9:57 AM, Coleen Phillimore wrote:

> 
> Hi,
> I have read through all of this code.  Offline to Keith, I have suggested some name changes and comments to make it clearer, at least to me, what this code is doing.  It's very dense but I believe it is correct and finds the correct default method to add to the vtable in the most efficient way possible.
> Keith, can you elaborate on the tests that you've run against this?
> Thanks,
> Coleen
> 
> On 10/10/2012 1:12 PM, Keith McGuigan wrote:
>> Hello,
>> 
>> I'd like any review of the code which implements default methods in the JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and tracked by CR 7200776.
>> 
>> The design and implementation is described in this short document:
>> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>> 
>> And the code is here:
>> http://cr.openjdk.java.net/~kamg/default_methods/
>> 
>> Any review (even partial) would be appreciated.  Thanks!
>> 
>> -- 
>> - Keith


From coleen.phillimore at oracle.com  Fri Oct 26 07:27:38 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 26 Oct 2012 10:27:38 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <B59E913B-F77E-45DF-94FC-4C0F7E02E2AA@oracle.com>
References: <5075AC78.3030702@oracle.com> <508A96C6.1080207@oracle.com>
	<B59E913B-F77E-45DF-94FC-4C0F7E02E2AA@oracle.com>
Message-ID: <508A9DDA.4090304@oracle.com>


Have you run our hotspot-rt nightly tests (vm.quick.testlist)?
thanks,
Coleen

On 10/26/2012 10:19 AM, Keith McGuigan wrote:
> Sure.  In addition to running the internal UTE/JCK tests, the same code has gone through testing as part of the lambda repositories.  There is new test-ng lambda tests in lambda/jdk/test-ng and lambda/jdk/combo-tests (run with ant).  And the entire lambda build (including the new VM bits) gets nightly testing that runs (at least) the workspace regression tests.
>
> --
> - Keith
>
> On Oct 26, 2012, at 9:57 AM, Coleen Phillimore wrote:
>
>> Hi,
>> I have read through all of this code.  Offline to Keith, I have suggested some name changes and comments to make it clearer, at least to me, what this code is doing.  It's very dense but I believe it is correct and finds the correct default method to add to the vtable in the most efficient way possible.
>> Keith, can you elaborate on the tests that you've run against this?
>> Thanks,
>> Coleen
>>
>> On 10/10/2012 1:12 PM, Keith McGuigan wrote:
>>> Hello,
>>>
>>> I'd like any review of the code which implements default methods in the JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and tracked by CR 7200776.
>>>
>>> The design and implementation is described in this short document:
>>> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>>>
>>> And the code is here:
>>> http://cr.openjdk.java.net/~kamg/default_methods/
>>>
>>> Any review (even partial) would be appreciated.  Thanks!
>>>
>>> -- 
>>> - Keith

From keith.mcguigan at oracle.com  Fri Oct 26 07:30:10 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Fri, 26 Oct 2012 10:30:10 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <508A9DDA.4090304@oracle.com>
References: <5075AC78.3030702@oracle.com> <508A96C6.1080207@oracle.com>
	<B59E913B-F77E-45DF-94FC-4C0F7E02E2AA@oracle.com>
	<508A9DDA.4090304@oracle.com>
Message-ID: <64630078-B038-49E7-B32C-C53688E8B23A@oracle.com>


Yes, but not with the latest changes.  I'll do it again.

On Oct 26, 2012, at 10:27 AM, Coleen Phillimore wrote:

> 
> Have you run our hotspot-rt nightly tests (vm.quick.testlist)?
> thanks,
> Coleen
> 
> On 10/26/2012 10:19 AM, Keith McGuigan wrote:
>> Sure.  In addition to running the internal UTE/JCK tests, the same code has gone through testing as part of the lambda repositories.  There is new test-ng lambda tests in lambda/jdk/test-ng and lambda/jdk/combo-tests (run with ant).  And the entire lambda build (including the new VM bits) gets nightly testing that runs (at least) the workspace regression tests.
>> 
>> --
>> - Keith
>> 
>> On Oct 26, 2012, at 9:57 AM, Coleen Phillimore wrote:
>> 
>>> Hi,
>>> I have read through all of this code.  Offline to Keith, I have suggested some name changes and comments to make it clearer, at least to me, what this code is doing.  It's very dense but I believe it is correct and finds the correct default method to add to the vtable in the most efficient way possible.
>>> Keith, can you elaborate on the tests that you've run against this?
>>> Thanks,
>>> Coleen
>>> 
>>> On 10/10/2012 1:12 PM, Keith McGuigan wrote:
>>>> Hello,
>>>> 
>>>> I'd like any review of the code which implements default methods in the JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and tracked by CR 7200776.
>>>> 
>>>> The design and implementation is described in this short document:
>>>> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>>>> 
>>>> And the code is here:
>>>> http://cr.openjdk.java.net/~kamg/default_methods/
>>>> 
>>>> Any review (even partial) would be appreciated.  Thanks!
>>>> 
>>>> -- 
>>>> - Keith


From kelly.ohair at oracle.com  Fri Oct 26 08:02:54 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 26 Oct 2012 08:02:54 -0700
Subject: Request for Review: Add hotspot support for building with
	mingw/msys on build-infra (the new build)
In-Reply-To: <508A441C.9070101@oracle.com>
References: <50894371.5010001@oracle.com>
	<08803191-4297-4464-B062-0F7010585D5F@oracle.com>
	<508A441C.9070101@oracle.com>
Message-ID: <359018D5-25D1-455A-9CF9-60F22CEB9E66@oracle.com>


On Oct 26, 2012, at 1:04 AM, Magnus Ihse Bursie wrote:

> On 2012-10-26 03:24, Kelly O'Hair wrote:
>> It has been my experience that using cygpath -w created problems with shell escape logic,
>> and that is why cygpath -m with a make level subst change is done, it was less problematic.
> It think it would work, but I understand why you are cautious. I can revert that part.
>> I don't understand why you would even want to change the cygwin logic at all, if it isn't broken why mess with it?
> It turned out that it was indeed broken, but I had forgot what I fixed. :-) The current code works if CC is defined like
> CC=/path/to/compiler
> but it will not work if CC is defined like
> CC=/path/to/compiler -extra -compiler -options
> That is what the $(firstword) stuff is about, just converting the compiler path.

But according to the GNU manual, http://www.gnu.org/software/make/manual/make.html#Implicit-Variables,
the CC name should be just a path to an executable, at least by convention, compiler flags belong in other variables.

> 
> This would be just a complaint in general that it broke expectations on how to setup CC, if not this turned out to be a problem for the latest changes in build-infra.
> 
> In older build-infra, we send in
> CC=/path/to/fixpath /path/to/compiler
> and by a lucky co-incidence, this will actually work, altough not as expected. (As far as I can understand, the hotspot makefile cygpath rewrite will change both paths.)

What "hotspot makefile cygpath rewrite" are we talking about here?

The CYGWIN cygpath utility, as far as I know, operates on one path or a PATH style path (path:path), not a
command line or series of blank separated paths.

> 
> However, when I added support for msys in build-infra, I changed the syntax for fixpath (formerly uncygdrive). It now requires an switch telling it to work in cygwin or msys mode, so we send in:
> CC=/path/to/fixpath -c /path/to/compiler
> which will make the hotspot rewrite code break. (My guess is that cygpath converts /path/to/fixpath but ignores everything from -c and forward).

If cygpath is given a command line, I think we may be in 'undefined' behavior, I'm not sure what it would do.

As I understand it, the uncygdrive (and fixpath) tool is intended to process a full command line, right?
But CYGWIN's cygpath utility is just for paths.  Or am I missing something here?

> 
> Since fixpath actually isn't technically needed when building hotspot, we can work around this differently in Hotspot. Maybe that is the pragmatic way. But I still believe it's theoretically wrong with not handling a CC= which contains more than a path to an executable. :-)

I tend to disagree, having multiple words in CC is unconventional, and if we do that, we need to consider the
consequences of straying from the typical make convention.
But I'd rather not get into what is theoretically wrong or right, it just needs to work, so we do what we have to.

The fixpath trick concerns me on windows, all the extra exec's and all, but I've kept quiet about it because I'm
not that up to speed on the specific issues. I think we need to watch fixpath pretty closely, something tells me
we aren't done with this issue, just a gut feeling.

> 
> 
>> So my suggestion would be to add the msys logic, and leave the old cygwin logic alone.
>> 
>> I could have sworn that Tim Bell already did this change, and yes, if I look at:
>> 
>>     http://hg.openjdk.java.net/jdk8/build/hotspot/file/dccd40de8db1/make/windows/makefiles/defs.make
>> 
>> These changes are there already, or something equivalent.
>> 
>> Have you talked with Tim Bell about this change?
> 
> Not specifically about this change, but we communicated a lot while I was developing msys support for build-infra.
> 
> I'm not sure what you want to tell me by the link. There was a change (7181175: Enable builds on Windows with MinGW/MSYS),
> http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0d8e265ba727
> which added the USING_MINGW variable that I need to check. However I can't see anything in this file that would fix the CXX etc variables for msys, the way my patch is doing it.
> 

You are correct that something needs to fix the multiple word issue of $(CC) for msys.

> But then again, we can probably do without this patch, if we make things differently in build-infra. We're already doing some weird special stuff for Hotspot builds that I guess adding another exception won't be that different. I'll look into it.

I appreciate that.

-kto

> 
> /Magnus


From keith.mcguigan at oracle.com  Fri Oct 26 08:07:46 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Fri, 26 Oct 2012 11:07:46 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <508A96C6.1080207@oracle.com>
References: <5075AC78.3030702@oracle.com> <508A96C6.1080207@oracle.com>
Message-ID: <3BCECE5D-8B12-4B10-B2BE-E2F3B1001FD9@oracle.com>


Thanks, Coleen, 

I need just one more reviewer.  If someone has time, here is the code and design/impl overview:

http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
http://cr.openjdk.java.net/~kamg/default_methods/

--
- Keith


On Oct 26, 2012, at 9:57 AM, Coleen Phillimore wrote:

> 
> Hi,
> I have read through all of this code.  Offline to Keith, I have suggested some name changes and comments to make it clearer, at least to me, what this code is doing.  It's very dense but I believe it is correct and finds the correct default method to add to the vtable in the most efficient way possible.
> Keith, can you elaborate on the tests that you've run against this?
> Thanks,
> Coleen
> 
> On 10/10/2012 1:12 PM, Keith McGuigan wrote:
>> Hello,
>> 
>> I'd like any review of the code which implements default methods in the JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and tracked by CR 7200776.
>> 
>> The design and implementation is described in this short document:
>> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>> 
>> And the code is here:
>> http://cr.openjdk.java.net/~kamg/default_methods/
>> 
>> Any review (even partial) would be appreciated.  Thanks!
>> 
>> -- 
>> - Keith


From magnus.ihse.bursie at oracle.com  Thu Oct 25 06:49:37 2012
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 25 Oct 2012 15:49:37 +0200
Subject: Request for Review: Add hotspot support for building with mingw/msys
	on build-infra (the new build)
Message-ID: <50894371.5010001@oracle.com>

The following patch will allow build-infra to perform builds on MinGW/MSys.

It also updates the case for cygwin, with the two changes:

1) It replaces a $(subst) from / to \ which acted on output from cygpath 
-m (mixed mode), with just cygpath -w (windows mode, i.e. mixed mode but 
with \ instead of /).

2) In analogy with the msys case, we only do path convertion of the 
first word (i.e. the executable), not any possibly following arguments. 
In reality, there are no argument in the cygwin case (in contrary to the 
msys case, where the build infra solution requires passing additional 
arguments to the binaries).

If these are problematic, they can be dropped. The important part, from 
build-infras point of view, is the mingw case.

http://cr.openjdk.java.net/~ihse/hotspot-build-infra-msys-support/webrev.00/

/Magnus

From magnus.ihse.bursie at oracle.com  Fri Oct 26 01:04:44 2012
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 26 Oct 2012 10:04:44 +0200
Subject: Request for Review: Add hotspot support for building with
	mingw/msys on build-infra (the new build)
In-Reply-To: <08803191-4297-4464-B062-0F7010585D5F@oracle.com>
References: <50894371.5010001@oracle.com>
	<08803191-4297-4464-B062-0F7010585D5F@oracle.com>
Message-ID: <508A441C.9070101@oracle.com>

On 2012-10-26 03:24, Kelly O'Hair wrote:
> It has been my experience that using cygpath -w created problems with shell escape logic,
> and that is why cygpath -m with a make level subst change is done, it was less problematic.
It think it would work, but I understand why you are cautious. I can 
revert that part.
> I don't understand why you would even want to change the cygwin logic at all, if it isn't broken why mess with it?
It turned out that it was indeed broken, but I had forgot what I fixed. 
:-) The current code works if CC is defined like
CC=/path/to/compiler
but it will not work if CC is defined like
CC=/path/to/compiler -extra -compiler -options
That is what the $(firstword) stuff is about, just converting the 
compiler path.

This would be just a complaint in general that it broke expectations on 
how to setup CC, if not this turned out to be a problem for the latest 
changes in build-infra.

In older build-infra, we send in
CC=/path/to/fixpath /path/to/compiler
and by a lucky co-incidence, this will actually work, altough not as 
expected. (As far as I can understand, the hotspot makefile cygpath 
rewrite will change both paths.)

However, when I added support for msys in build-infra, I changed the 
syntax for fixpath (formerly uncygdrive). It now requires an switch 
telling it to work in cygwin or msys mode, so we send in:
CC=/path/to/fixpath -c /path/to/compiler
which will make the hotspot rewrite code break. (My guess is that 
cygpath converts /path/to/fixpath but ignores everything from -c and 
forward).

Since fixpath actually isn't technically needed when building hotspot, 
we can work around this differently in Hotspot. Maybe that is the 
pragmatic way. But I still believe it's theoretically wrong with not 
handling a CC= which contains more than a path to an executable. :-)


> So my suggestion would be to add the msys logic, and leave the old cygwin logic alone.
>
> I could have sworn that Tim Bell already did this change, and yes, if I look at:
>
>      http://hg.openjdk.java.net/jdk8/build/hotspot/file/dccd40de8db1/make/windows/makefiles/defs.make
>
> These changes are there already, or something equivalent.
>
> Have you talked with Tim Bell about this change?

Not specifically about this change, but we communicated a lot while I 
was developing msys support for build-infra.

I'm not sure what you want to tell me by the link. There was a change 
(7181175: Enable builds on Windows with MinGW/MSYS),
http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0d8e265ba727
which added the USING_MINGW variable that I need to check. However I 
can't see anything in this file that would fix the CXX etc variables for 
msys, the way my patch is doing it.

But then again, we can probably do without this patch, if we make things 
differently in build-infra. We're already doing some weird special stuff 
for Hotspot builds that I guess adding another exception won't be that 
different. I'll look into it.

/Magnus

From magnus.ihse.bursie at oracle.com  Fri Oct 26 05:48:35 2012
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 26 Oct 2012 14:48:35 +0200
Subject: Request for Review: Add hotspot support for building with
	mingw/msys on build-infra (the new build)
In-Reply-To: <508A441C.9070101@oracle.com>
References: <50894371.5010001@oracle.com>
	<08803191-4297-4464-B062-0F7010585D5F@oracle.com>
	<508A441C.9070101@oracle.com>
Message-ID: <508A86A3.9060902@oracle.com>

On 2012-10-26 10:04, Magnus Ihse Bursie wrote:
> Since fixpath actually isn't technically needed when building hotspot, 
> we can work around this differently in Hotspot. Maybe that is the 
> pragmatic way. But I still believe it's theoretically wrong with not 
> handling a CC= which contains more than a path to an executable. :-)
> ...
> But then again, we can probably do without this patch, if we make 
> things differently in build-infra. We're already doing some weird 
> special stuff for Hotspot builds that I guess adding another exception 
> won't be that different. I'll look into it.

I just pushed a fix for this in build-infra, meaning this patch is not 
needed anymore. Let's drop it.

(Kelly: it also means that now your JPRT Windows runs should work out 
fine! :-))

/Magnus

From tim.bell at oracle.com  Fri Oct 26 10:14:40 2012
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 26 Oct 2012 10:14:40 -0700
Subject: JPRT system changes
In-Reply-To: <BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>
	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>
	<508ABAD4.6040400@oracle.com>
	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>
Message-ID: <508AC500.10801@oracle.com>

Adding hotspot-dev for the question about jbb_default below.

Kelly-

> I'll be taking all the Windows 7 systems out of the queues until we resolve this.

Rather than take them out, could you make thw W7 systems build-only?

The root of the problem is that jbb does not really run properly in 
headless mode.  Everything after that has been us standing on our heads 
trying to work around breakage in jbb or in AWT.

Is jbb_default worth keeping, or is it simply run out of habit? Just 
asking because it is causing a fair amount of trouble.


Tim

On 10/26/12 09:56, Kelly O'Hair wrote:
> It's the Windows 7 jbb issue.
>
> We have seen this before in JPRT Stockholm, which was the first JPRT system that had Windows 7.
>
> Current theory, not sure how much we understand this, is that the CYGWIN sshd service is somehow
> involved, and that if we manually start sshd the hang goes away.
> But so far we haven't had any solutions on how to get this manual sshd startup to work on reboots.
>
> I'll be taking all the Windows 7 systems out of the queues until we resolve this.
>
> -kto
>
> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>
>> It looks like some of new machines periodically timeout during jbb test run (>25min) so out jobs failed.
>>
>>   windows_x64-fastdebug-c2-jbb_default              FAILED(25m 40s)
>>         USED:     hostname=sc11136526 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>         ATTRS:    cygwin=true
>>         TIMING:   clean=1s init=13s work=25m12s fini=5s
>>         VMFLAGS:  -server -Djava.awt.headless=true
>>         NEEDS:    cygwin,gnumake381,jbb,jtreg
>>
>>
>>   windows_x64-fastdebug-c2-jbb_default              FAILED(25m 50s)
>>         USED:     hostname=sc11136603 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>         ATTRS:    mks=true
>>         TIMING:   clean=12s init=13s work=25m13s fini=4s
>>         VMFLAGS:  -server -Djava.awt.headless=true
>>         NEEDS:    gnumake381,jbb,jtreg,mks
>>
>> Vladimir
>>
>> Kelly O'Hair wrote:
>>> I have updated all the JPRT systems to a new version.
>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>> Changes:
>>> * hotspotwest will get all the Windows X64 machines currently used by the sfbay queue (4 X64 systems, 1 is a VM)
>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64 DevOp VMs
>>> * some changes with regards to how JPRT kills off processes on clients, should help kill off failed or hung cygwin builds
>>> * An attempt to allow ccache to work on Solaris with build-infra builds
>>> There are some JPRT sfbay machines that are down, tickets have been filed. So sfbay is shy Solaris SPARC and one MacPro.
>>> JPRT East is missing some Solaris SPARC machines.
>>> -kto



From vladimir.kozlov at oracle.com  Fri Oct 26 10:14:21 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Oct 2012 10:14:21 -0700
Subject: JPRT system changes
In-Reply-To: <508AC500.10801@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>
	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>
	<508ABAD4.6040400@oracle.com>
	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>
	<508AC500.10801@oracle.com>
Message-ID: <508AC4ED.1070901@oracle.com>

Tim,

It is not just JBB. Here is current status:

   [ 3 windows_x64_6.1 clients, 3 hosts ]
     sc11136526(P1)[DevOps VM Windows 7 X64]: running 
<2012-10-26-154155.jcoomes.gc-push> windows_x64-product-c2-GCBasher_ParOldGC(46m 
40s)
     sc11136598(P1)[DevOps VM Windows 7 X64]: running 
<2012-10-26-003719.vkozlov.7163534> 
windows_x64-fastdebug-c2-jbb_default_nontiered(56m 10s)
     sc11136603(P1)[DevOps VM Windows 7 X64]: running 
<2012-10-26-154155.jcoomes.gc-push> windows_x64-product-c2-runThese_Xcomp(36m 52s)

Vladimir

Tim Bell wrote:
> Adding hotspot-dev for the question about jbb_default below.
> 
> Kelly-
> 
>> I'll be taking all the Windows 7 systems out of the queues until we 
>> resolve this.
> 
> Rather than take them out, could you make thw W7 systems build-only?
> 
> The root of the problem is that jbb does not really run properly in 
> headless mode.  Everything after that has been us standing on our heads 
> trying to work around breakage in jbb or in AWT.
> 
> Is jbb_default worth keeping, or is it simply run out of habit? Just 
> asking because it is causing a fair amount of trouble.
> 
> 
> Tim
> 
> On 10/26/12 09:56, Kelly O'Hair wrote:
>> It's the Windows 7 jbb issue.
>>
>> We have seen this before in JPRT Stockholm, which was the first JPRT 
>> system that had Windows 7.
>>
>> Current theory, not sure how much we understand this, is that the 
>> CYGWIN sshd service is somehow
>> involved, and that if we manually start sshd the hang goes away.
>> But so far we haven't had any solutions on how to get this manual sshd 
>> startup to work on reboots.
>>
>> I'll be taking all the Windows 7 systems out of the queues until we 
>> resolve this.
>>
>> -kto
>>
>> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>>
>>> It looks like some of new machines periodically timeout during jbb 
>>> test run (>25min) so out jobs failed.
>>>
>>>   windows_x64-fastdebug-c2-jbb_default              FAILED(25m 40s)
>>>         USED:     hostname=sc11136526 platform=windows_x64_6.1 
>>> osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB 
>>> instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true 
>>> dxsdk=true pstools=true
>>>         ATTRS:    cygwin=true
>>>         TIMING:   clean=1s init=13s work=25m12s fini=5s
>>>         VMFLAGS:  -server -Djava.awt.headless=true
>>>         NEEDS:    cygwin,gnumake381,jbb,jtreg
>>>
>>>
>>>   windows_x64-fastdebug-c2-jbb_default              FAILED(25m 50s)
>>>         USED:     hostname=sc11136603 platform=windows_x64_6.1 
>>> osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB 
>>> instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true 
>>> dxsdk=true pstools=true
>>>         ATTRS:    mks=true
>>>         TIMING:   clean=12s init=13s work=25m13s fini=4s
>>>         VMFLAGS:  -server -Djava.awt.headless=true
>>>         NEEDS:    gnumake381,jbb,jtreg,mks
>>>
>>> Vladimir
>>>
>>> Kelly O'Hair wrote:
>>>> I have updated all the JPRT systems to a new version.
>>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>>> Changes:
>>>> * hotspotwest will get all the Windows X64 machines currently used 
>>>> by the sfbay queue (4 X64 systems, 1 is a VM)
>>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64 DevOp 
>>>> VMs
>>>> * some changes with regards to how JPRT kills off processes on 
>>>> clients, should help kill off failed or hung cygwin builds
>>>> * An attempt to allow ccache to work on Solaris with build-infra builds
>>>> There are some JPRT sfbay machines that are down, tickets have been 
>>>> filed. So sfbay is shy Solaris SPARC and one MacPro.
>>>> JPRT East is missing some Solaris SPARC machines.
>>>> -kto
> 
> 

From jiangli.zhou at oracle.com  Fri Oct 26 10:16:40 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 26 Oct 2012 10:16:40 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <508A4CD4.2090009@oracle.com>
References: <5089C7E1.2040206@oracle.com> <508A4CD4.2090009@oracle.com>
Message-ID: <508AC578.2000603@oracle.com>

Hi Alan,

Thanks for bring up the -timeoutFactor option. I was told about the 
option but didn't go that way. Looking at the jdk/make directory now, 
there are individual Makefile under each test directory (wasn't aware 
that earlier). If we can just control the java/lang/invoke tests timeout 
factor by adding the option in  jdk/make/java/invoke/Makefile, that 
seems to be a better way than changing individual test as there are 
multiple tests in the category times out.

Thanks,

Jiangli

On 10/26/2012 01:41 AM, Alan Bateman wrote:
> On 26/10/2012 00:14, Jiangli Zhou wrote:
>> Hi,
>>
>> Please review the timeout change to 
>> test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes 
>> longer time to execute on certain embedded devices. It takes about 23 
>> minutes to run on an ARM softfloat device with fastdebug binary. 
>> Using a 2000s timeout here just to be sure.
>>
>>   http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
>>
>> Thanks,
>> Jiangli
>>
> You might know this already but the jtreg -timeoutFactor option can be 
> used to apply a scaling factor to the timeout. This may not be fine 
> grained enough to only increase it for tests that are floating point 
> intensive but it is generally useful to use this when running tests on 
> slow machines. The downside is that it increases the overall execution 
> time when there are tests that fail due to reaching the timeout (but 
> such tests could be added to the exclude list to avoid running them).
>
> -Alan


From tim.bell at oracle.com  Fri Oct 26 10:31:45 2012
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 26 Oct 2012 10:31:45 -0700
Subject: JPRT system changes
In-Reply-To: <508AC4ED.1070901@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>
	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>
	<508ABAD4.6040400@oracle.com>
	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>
	<508AC500.10801@oracle.com> <508AC4ED.1070901@oracle.com>
Message-ID: <508AC901.3030708@oracle.com>

On 10/26/12 10:14, Vladimir Kozlov wrote:
> Tim,
>
> It is not just JBB. Here is current status:

Hmmm... not sure what it is, then.

>   [ 3 windows_x64_6.1 clients, 3 hosts ]
>     sc11136526(P1)[DevOps VM Windows 7 X64]: running 
> <2012-10-26-154155.jcoomes.gc-push> 
> windows_x64-product-c2-GCBasher_ParOldGC(46m 40s)

No traces of that job on sc11136526:

jprtadm at SC11136526:/cygdrive/c/MKS/mksnt> cd /cygdrive/c/MKS/mksnt && 
./ps -ef | grep $USER
  jprtadm   1092    524  0   Oct 20 con  0:00 C:\cygwin\bin\cygrunsrv.exe
  jprtadm   1116    376  0   Oct 20 con  0:04 
\??\C:\Windows\system32\conhost.exe 
"-1483141665-707719824-1770841038-590923786-3215500991937909109-844736201686794369
  jprtadm   1476   1140  0   Oct 20 con  0:01 C:\cygwin\usr\sbin\sshd.exe -D
  jprtadm   1196    524  0   Oct 24 con  0:00 "taskhost.exe"
  jprtadm   1652    372  0   Oct 24 con  0:00 rdpclip
  jprtadm   2052    864  0   Oct 24 con  0:00 "C:\Windows\system32\Dwm.exe"
  jprtadm   3572   3536  0   Oct 24 con  0:05 C:\Windows\Explorer.EXE
  jprtadm   1992   3084  0   Oct 24 con  0:00 "C:\Program Files 
(x86)\Common Files\Java\Java Update\jucheck.exe" -auto -scheduled -critical
  jprtadm   2580   1316  0   Oct 24 con  0:00 "C:\Program Files 
(x86)\McAfee\Common Framework\UdaterUI.exe" 
/EventName=UPDATER_UI_EVENT128252be
  jprtadm   1552   2580  0   Oct 24 con  0:00 /load
  jprtadm   4012   3188  0 10:17:05 con  0:00 
C:\cygwin\usr\sbin\sshd.exe -D -R
  jprtadm   3136   4108  0 10:17:07 con  0:00 C:\cygwin\bin\bash.exe
  jprtadm   3044   3136  0 10:19:33 con  0:00 C:\cygwin\bin\bash.exe
  jprtadm   3796   3044  0 10:19:33 con  0:00 C:\MKS\mksnt\ps.exe -ef
  jprtadm   3372   3796  0 10:19:33 con  0:00 ntps.exe -ef
  jprtadm   2000   4824  0 10:19:33 con  0:00 C:\cygwin\bin\grep.exe jprtadm


> sc11136598(P1)[DevOps VM Windows 7 X64]: running 
> <2012-10-26-003719.vkozlov.7163534> 
> windows_x64-fastdebug-c2-jbb_default_nontiered(56m 10s)

No sign of that job on sc11136598:

jprtadm at SC11136598:/cygdrive/c/MKS/mksnt> cd /cygdrive/c/MKS/mksnt && 
./ps -ef | grep $USER
  jprtadm   3156    524  0   Oct 24 con  0:00 "taskhost.exe"
  jprtadm    600    372  0   Oct 24 con  0:00 rdpclip
  jprtadm   2472    860  0   Oct 24 con  0:00 "C:\Windows\system32\Dwm.exe"
  jprtadm   3196    588  0   Oct 24 con  0:04 C:\Windows\Explorer.EXE
  jprtadm   3940   3724  0   Oct 24 con  0:00 "C:\Program Files 
(x86)\Common Files\Java\Java Update\jusched.exe"
  jprtadm   1904   3724  0   Oct 24 con  0:01 "C:\Program Files 
(x86)\McAfee\Host Intrusion Prevention\FireTray.exe"
  jprtadm   3504   1392  0   Oct 24 con  0:00 "C:\Program Files 
(x86)\McAfee\Common Framework\UdaterUI.exe" 
/EventName=UPDATER_UI_EVENT12e6c98d
  jprtadm   1816   3504  0   Oct 24 con  0:00 /load
  jprtadm   2332   3940  0   Oct 24 con  0:00 "C:\Program Files 
(x86)\Common Files\Java\Java Update\jucheck.exe" -auto -scheduled -critical
  jprtadm   4796    524  0 09:37:10 con  0:00 C:\cygwin\bin\cygrunsrv.exe
  jprtadm   5880    376  0 09:37:10 con  0:00 
\??\C:\Windows\system32\conhost.exe 
"-1794119873914084936-13665211491113271794989327951480364587-1969885781-473977465
  jprtadm   4512    824  0 09:37:10 con  0:00 C:\cygwin\usr\sbin\sshd.exe -D
  jprtadm   5500   5532  0 10:20:33 con  0:00 
C:\cygwin\usr\sbin\sshd.exe -D -R
  jprtadm   5612   4044  0 10:20:35 con  0:00 C:\cygwin\bin\bash.exe
  jprtadm   1776   5612  0 10:20:56 con  0:00 C:\cygwin\bin\bash.exe
  jprtadm   5556   1776  0 10:20:56 con  0:00 C:\MKS\mksnt\ps.exe -ef
  jprtadm   2544   2268  0 10:20:56 con  0:00 C:\cygwin\bin\grep.exe jprtadm
  jprtadm   3864   5556  0 10:20:56 con  0:00 ntps.exe -ef

> sc11136603(P1)[DevOps VM Windows 7 X64]: running 
> <2012-10-26-154155.jcoomes.gc-push> 
> windows_x64-product-c2-runThese_Xcomp(36m 52s)

sc11136603 is not responding to ssh or to remote desktop.


Tim

>
> Vladimir
>
> Tim Bell wrote:
>> Adding hotspot-dev for the question about jbb_default below.
>>
>> Kelly-
>>
>>> I'll be taking all the Windows 7 systems out of the queues until we 
>>> resolve this.
>>
>> Rather than take them out, could you make thw W7 systems build-only?
>>
>> The root of the problem is that jbb does not really run properly in 
>> headless mode.  Everything after that has been us standing on our 
>> heads trying to work around breakage in jbb or in AWT.
>>
>> Is jbb_default worth keeping, or is it simply run out of habit? Just 
>> asking because it is causing a fair amount of trouble.
>>
>>
>> Tim
>>
>> On 10/26/12 09:56, Kelly O'Hair wrote:
>>> It's the Windows 7 jbb issue.
>>>
>>> We have seen this before in JPRT Stockholm, which was the first JPRT 
>>> system that had Windows 7.
>>>
>>> Current theory, not sure how much we understand this, is that the 
>>> CYGWIN sshd service is somehow
>>> involved, and that if we manually start sshd the hang goes away.
>>> But so far we haven't had any solutions on how to get this manual 
>>> sshd startup to work on reboots.
>>>
>>> I'll be taking all the Windows 7 systems out of the queues until we 
>>> resolve this.
>>>
>>> -kto
>>>
>>> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>>>
>>>> It looks like some of new machines periodically timeout during jbb 
>>>> test run (>25min) so out jobs failed.
>>>>
>>>>   windows_x64-fastdebug-c2-jbb_default FAILED(25m 40s)
>>>>         USED:     hostname=sc11136526 platform=windows_x64_6.1 
>>>> osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB 
>>>> instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true 
>>>> dxsdk=true pstools=true
>>>>         ATTRS:    cygwin=true
>>>>         TIMING:   clean=1s init=13s work=25m12s fini=5s
>>>>         VMFLAGS:  -server -Djava.awt.headless=true
>>>>         NEEDS:    cygwin,gnumake381,jbb,jtreg
>>>>
>>>>
>>>>   windows_x64-fastdebug-c2-jbb_default FAILED(25m 50s)
>>>>         USED:     hostname=sc11136603 platform=windows_x64_6.1 
>>>> osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB 
>>>> instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true 
>>>> dxsdk=true pstools=true
>>>>         ATTRS:    mks=true
>>>>         TIMING:   clean=12s init=13s work=25m13s fini=4s
>>>>         VMFLAGS:  -server -Djava.awt.headless=true
>>>>         NEEDS:    gnumake381,jbb,jtreg,mks
>>>>
>>>> Vladimir
>>>>
>>>> Kelly O'Hair wrote:
>>>>> I have updated all the JPRT systems to a new version.
>>>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>>>> Changes:
>>>>> * hotspotwest will get all the Windows X64 machines currently used 
>>>>> by the sfbay queue (4 X64 systems, 1 is a VM)
>>>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64 
>>>>> DevOp VMs
>>>>> * some changes with regards to how JPRT kills off processes on 
>>>>> clients, should help kill off failed or hung cygwin builds
>>>>> * An attempt to allow ccache to work on Solaris with build-infra 
>>>>> builds
>>>>> There are some JPRT sfbay machines that are down, tickets have 
>>>>> been filed. So sfbay is shy Solaris SPARC and one MacPro.
>>>>> JPRT East is missing some Solaris SPARC machines.
>>>>> -kto
>>
>>



From kelly.ohair at oracle.com  Fri Oct 26 10:52:03 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 26 Oct 2012 10:52:03 -0700
Subject: JPRT system changes
In-Reply-To: <508AC901.3030708@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>
	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>
	<508ABAD4.6040400@oracle.com>
	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>
	<508AC500.10801@oracle.com> <508AC4ED.1070901@oracle.com>
	<508AC901.3030708@oracle.com>
Message-ID: <457144C3-C47F-435A-BF66-E94B06F053AB@oracle.com>


On Oct 26, 2012, at 10:31 AM, Tim Bell wrote:

> On 10/26/12 10:14, Vladimir Kozlov wrote:
>> Tim,
>> 
>> It is not just JBB. Here is current status:
> 
> Hmmm... not sure what it is, then.
> 
>>  [ 3 windows_x64_6.1 clients, 3 hosts ]
>>    sc11136526(P1)[DevOps VM Windows 7 X64]: running <2012-10-26-154155.jcoomes.gc-push> windows_x64-product-c2-GCBasher_ParOldGC(46m 40s)
> 
> No traces of that job on sc11136526:

I'm trying to kill off the JPRT client on these systems.

> 
> jprtadm at SC11136526:/cygdrive/c/MKS/mksnt> cd /cygdrive/c/MKS/mksnt && ./ps -ef | grep $USER
> jprtadm   1092    524  0   Oct 20 con  0:00 C:\cygwin\bin\cygrunsrv.exe
> jprtadm   1116    376  0   Oct 20 con  0:04 \??\C:\Windows\system32\conhost.exe "-1483141665-707719824-1770841038-590923786-3215500991937909109-844736201686794369
> jprtadm   1476   1140  0   Oct 20 con  0:01 C:\cygwin\usr\sbin\sshd.exe -D
> jprtadm   1196    524  0   Oct 24 con  0:00 "taskhost.exe"
> jprtadm   1652    372  0   Oct 24 con  0:00 rdpclip
> jprtadm   2052    864  0   Oct 24 con  0:00 "C:\Windows\system32\Dwm.exe"
> jprtadm   3572   3536  0   Oct 24 con  0:05 C:\Windows\Explorer.EXE
> jprtadm   1992   3084  0   Oct 24 con  0:00 "C:\Program Files (x86)\Common Files\Java\Java Update\jucheck.exe" -auto -scheduled -critical
> jprtadm   2580   1316  0   Oct 24 con  0:00 "C:\Program Files (x86)\McAfee\Common Framework\UdaterUI.exe" /EventName=UPDATER_UI_EVENT128252be
> jprtadm   1552   2580  0   Oct 24 con  0:00 /load
> jprtadm   4012   3188  0 10:17:05 con  0:00 C:\cygwin\usr\sbin\sshd.exe -D -R
> jprtadm   3136   4108  0 10:17:07 con  0:00 C:\cygwin\bin\bash.exe
> jprtadm   3044   3136  0 10:19:33 con  0:00 C:\cygwin\bin\bash.exe
> jprtadm   3796   3044  0 10:19:33 con  0:00 C:\MKS\mksnt\ps.exe -ef
> jprtadm   3372   3796  0 10:19:33 con  0:00 ntps.exe -ef
> jprtadm   2000   4824  0 10:19:33 con  0:00 C:\cygwin\bin\grep.exe jprtadm
> 
> 
>> sc11136598(P1)[DevOps VM Windows 7 X64]: running <2012-10-26-003719.vkozlov.7163534> windows_x64-fastdebug-c2-jbb_default_nontiered(56m 10s)
> 
> No sign of that job on sc11136598:
> 
> jprtadm at SC11136598:/cygdrive/c/MKS/mksnt> cd /cygdrive/c/MKS/mksnt && ./ps -ef | grep $USER
> jprtadm   3156    524  0   Oct 24 con  0:00 "taskhost.exe"
> jprtadm    600    372  0   Oct 24 con  0:00 rdpclip
> jprtadm   2472    860  0   Oct 24 con  0:00 "C:\Windows\system32\Dwm.exe"
> jprtadm   3196    588  0   Oct 24 con  0:04 C:\Windows\Explorer.EXE
> jprtadm   3940   3724  0   Oct 24 con  0:00 "C:\Program Files (x86)\Common Files\Java\Java Update\jusched.exe"
> jprtadm   1904   3724  0   Oct 24 con  0:01 "C:\Program Files (x86)\McAfee\Host Intrusion Prevention\FireTray.exe"
> jprtadm   3504   1392  0   Oct 24 con  0:00 "C:\Program Files (x86)\McAfee\Common Framework\UdaterUI.exe" /EventName=UPDATER_UI_EVENT12e6c98d
> jprtadm   1816   3504  0   Oct 24 con  0:00 /load
> jprtadm   2332   3940  0   Oct 24 con  0:00 "C:\Program Files (x86)\Common Files\Java\Java Update\jucheck.exe" -auto -scheduled -critical
> jprtadm   4796    524  0 09:37:10 con  0:00 C:\cygwin\bin\cygrunsrv.exe
> jprtadm   5880    376  0 09:37:10 con  0:00 \??\C:\Windows\system32\conhost.exe "-1794119873914084936-13665211491113271794989327951480364587-1969885781-473977465
> jprtadm   4512    824  0 09:37:10 con  0:00 C:\cygwin\usr\sbin\sshd.exe -D
> jprtadm   5500   5532  0 10:20:33 con  0:00 C:\cygwin\usr\sbin\sshd.exe -D -R
> jprtadm   5612   4044  0 10:20:35 con  0:00 C:\cygwin\bin\bash.exe
> jprtadm   1776   5612  0 10:20:56 con  0:00 C:\cygwin\bin\bash.exe
> jprtadm   5556   1776  0 10:20:56 con  0:00 C:\MKS\mksnt\ps.exe -ef
> jprtadm   2544   2268  0 10:20:56 con  0:00 C:\cygwin\bin\grep.exe jprtadm
> jprtadm   3864   5556  0 10:20:56 con  0:00 ntps.exe -ef
> 
>> sc11136603(P1)[DevOps VM Windows 7 X64]: running <2012-10-26-154155.jcoomes.gc-push> windows_x64-product-c2-runThese_Xcomp(36m 52s)
> 
> sc11136603 is not responding to ssh or to remote desktop.

Not sure what happened on that system.

You will need to reboot via the DevOps interface, I can't do that since the machine is assigned to you.


-kto

> 
> 
> Tim
> 
>> 
>> Vladimir
>> 
>> Tim Bell wrote:
>>> Adding hotspot-dev for the question about jbb_default below.
>>> 
>>> Kelly-
>>> 
>>>> I'll be taking all the Windows 7 systems out of the queues until we resolve this.
>>> 
>>> Rather than take them out, could you make thw W7 systems build-only?
>>> 
>>> The root of the problem is that jbb does not really run properly in headless mode.  Everything after that has been us standing on our heads trying to work around breakage in jbb or in AWT.
>>> 
>>> Is jbb_default worth keeping, or is it simply run out of habit? Just asking because it is causing a fair amount of trouble.
>>> 
>>> 
>>> Tim
>>> 
>>> On 10/26/12 09:56, Kelly O'Hair wrote:
>>>> It's the Windows 7 jbb issue.
>>>> 
>>>> We have seen this before in JPRT Stockholm, which was the first JPRT system that had Windows 7.
>>>> 
>>>> Current theory, not sure how much we understand this, is that the CYGWIN sshd service is somehow
>>>> involved, and that if we manually start sshd the hang goes away.
>>>> But so far we haven't had any solutions on how to get this manual sshd startup to work on reboots.
>>>> 
>>>> I'll be taking all the Windows 7 systems out of the queues until we resolve this.
>>>> 
>>>> -kto
>>>> 
>>>> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>>>> 
>>>>> It looks like some of new machines periodically timeout during jbb test run (>25min) so out jobs failed.
>>>>> 
>>>>>  windows_x64-fastdebug-c2-jbb_default FAILED(25m 40s)
>>>>>        USED:     hostname=sc11136526 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>>>>        ATTRS:    cygwin=true
>>>>>        TIMING:   clean=1s init=13s work=25m12s fini=5s
>>>>>        VMFLAGS:  -server -Djava.awt.headless=true
>>>>>        NEEDS:    cygwin,gnumake381,jbb,jtreg
>>>>> 
>>>>> 
>>>>>  windows_x64-fastdebug-c2-jbb_default FAILED(25m 50s)
>>>>>        USED:     hostname=sc11136603 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>>>>        ATTRS:    mks=true
>>>>>        TIMING:   clean=12s init=13s work=25m13s fini=4s
>>>>>        VMFLAGS:  -server -Djava.awt.headless=true
>>>>>        NEEDS:    gnumake381,jbb,jtreg,mks
>>>>> 
>>>>> Vladimir
>>>>> 
>>>>> Kelly O'Hair wrote:
>>>>>> I have updated all the JPRT systems to a new version.
>>>>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>>>>> Changes:
>>>>>> * hotspotwest will get all the Windows X64 machines currently used by the sfbay queue (4 X64 systems, 1 is a VM)
>>>>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>>>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64 DevOp VMs
>>>>>> * some changes with regards to how JPRT kills off processes on clients, should help kill off failed or hung cygwin builds
>>>>>> * An attempt to allow ccache to work on Solaris with build-infra builds
>>>>>> There are some JPRT sfbay machines that are down, tickets have been filed. So sfbay is shy Solaris SPARC and one MacPro.
>>>>>> JPRT East is missing some Solaris SPARC machines.
>>>>>> -kto
>>> 
>>> 
> 
> 


From tim.bell at oracle.com  Fri Oct 26 11:00:06 2012
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 26 Oct 2012 11:00:06 -0700
Subject: JPRT system changes
In-Reply-To: <457144C3-C47F-435A-BF66-E94B06F053AB@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>
	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>
	<508ABAD4.6040400@oracle.com>
	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>
	<508AC500.10801@oracle.com> <508AC4ED.1070901@oracle.com>
	<508AC901.3030708@oracle.com>
	<457144C3-C47F-435A-BF66-E94B06F053AB@oracle.com>
Message-ID: <508ACFA6.80407@oracle.com>

On 10/26/12 10:52, Kelly O'Hair wrote:
>> sc11136603 is not responding to ssh or to remote desktop.
> Not sure what happened on that system.
>
> You will need to reboot via the DevOps interface, I can't do that since the machine is assigned to you.

DevOps says:

*Ping Status: Down at last interval (Auto-reboot enabled.) Down since 
2012-10-26 10:43:00.266461.     Total failed pings: 5.     Last seen up 
at: 2012-10-26 09:27:45.999651.

*

% date
Fri Oct 26 10:59:10 PDT 2012

A reboot has been initiated for sc11136603.

Tim


From kelly.ohair at oracle.com  Fri Oct 26 11:14:05 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 26 Oct 2012 11:14:05 -0700
Subject: JPRT system changes
In-Reply-To: <508AC500.10801@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>
	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>
	<508ABAD4.6040400@oracle.com>
	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>
	<508AC500.10801@oracle.com>
Message-ID: <477AAC1D-CF92-4504-B83B-23EBD6CC108B@oracle.com>


On Oct 26, 2012, at 10:14 AM, Tim Bell wrote:

> Adding hotspot-dev for the question about jbb_default below.
> 
> Kelly-
> 
>> I'll be taking all the Windows 7 systems out of the queues until we resolve this.
> 
> Rather than take them out, could you make thw W7 systems build-only?

We could do that, but I had hopes we had a solution that we could deploy and bury this issue for good.

> 
> The root of the problem is that jbb does not really run properly in headless mode.  Everything after that has been us standing on our heads trying to work around breakage in jbb or in AWT.

Yeah, this is annoying.

> 
> Is jbb_default worth keeping, or is it simply run out of habit? Just asking because it is causing a fair amount of trouble.

I think it's all jbb variations, not just jbb_default, right?

-kto

> 
> 
> Tim
> 
> On 10/26/12 09:56, Kelly O'Hair wrote:
>> It's the Windows 7 jbb issue.
>> 
>> We have seen this before in JPRT Stockholm, which was the first JPRT system that had Windows 7.
>> 
>> Current theory, not sure how much we understand this, is that the CYGWIN sshd service is somehow
>> involved, and that if we manually start sshd the hang goes away.
>> But so far we haven't had any solutions on how to get this manual sshd startup to work on reboots.
>> 
>> I'll be taking all the Windows 7 systems out of the queues until we resolve this.
>> 
>> -kto
>> 
>> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>> 
>>> It looks like some of new machines periodically timeout during jbb test run (>25min) so out jobs failed.
>>> 
>>>  windows_x64-fastdebug-c2-jbb_default              FAILED(25m 40s)
>>>        USED:     hostname=sc11136526 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>>        ATTRS:    cygwin=true
>>>        TIMING:   clean=1s init=13s work=25m12s fini=5s
>>>        VMFLAGS:  -server -Djava.awt.headless=true
>>>        NEEDS:    cygwin,gnumake381,jbb,jtreg
>>> 
>>> 
>>>  windows_x64-fastdebug-c2-jbb_default              FAILED(25m 50s)
>>>        USED:     hostname=sc11136603 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>>        ATTRS:    mks=true
>>>        TIMING:   clean=12s init=13s work=25m13s fini=4s
>>>        VMFLAGS:  -server -Djava.awt.headless=true
>>>        NEEDS:    gnumake381,jbb,jtreg,mks
>>> 
>>> Vladimir
>>> 
>>> Kelly O'Hair wrote:
>>>> I have updated all the JPRT systems to a new version.
>>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>>> Changes:
>>>> * hotspotwest will get all the Windows X64 machines currently used by the sfbay queue (4 X64 systems, 1 is a VM)
>>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64 DevOp VMs
>>>> * some changes with regards to how JPRT kills off processes on clients, should help kill off failed or hung cygwin builds
>>>> * An attempt to allow ccache to work on Solaris with build-infra builds
>>>> There are some JPRT sfbay machines that are down, tickets have been filed. So sfbay is shy Solaris SPARC and one MacPro.
>>>> JPRT East is missing some Solaris SPARC machines.
>>>> -kto
> 
> 


From vladimir.kozlov at oracle.com  Fri Oct 26 11:28:40 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Oct 2012 11:28:40 -0700
Subject: JPRT system changes
In-Reply-To: <477AAC1D-CF92-4504-B83B-23EBD6CC108B@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>	<508ABAD4.6040400@oracle.com>	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>	<508AC500.10801@oracle.com>
	<477AAC1D-CF92-4504-B83B-23EBD6CC108B@oracle.com>
Message-ID: <508AD658.5070102@oracle.com>

 > I think it's all jbb variations, not just jbb_default, right?

I saw it failed only with fastdebug VM and we run only default version on Win64:

     ${jprt.my.windows.x64}-{product|fastdebug}-c2-jbb_default, \
     ${jprt.my.windows.x64}-{product|fastdebug}-c2-jbb_default_nontiered, \

Vladimir

Kelly O'Hair wrote:
> On Oct 26, 2012, at 10:14 AM, Tim Bell wrote:
> 
>> Adding hotspot-dev for the question about jbb_default below.
>>
>> Kelly-
>>
>>> I'll be taking all the Windows 7 systems out of the queues until we resolve this.
>> Rather than take them out, could you make thw W7 systems build-only?
> 
> We could do that, but I had hopes we had a solution that we could deploy and bury this issue for good.
> 
>> The root of the problem is that jbb does not really run properly in headless mode.  Everything after that has been us standing on our heads trying to work around breakage in jbb or in AWT.
> 
> Yeah, this is annoying.
> 
>> Is jbb_default worth keeping, or is it simply run out of habit? Just asking because it is causing a fair amount of trouble.
> 
> I think it's all jbb variations, not just jbb_default, right?
> 
> -kto
> 
>>
>> Tim
>>
>> On 10/26/12 09:56, Kelly O'Hair wrote:
>>> It's the Windows 7 jbb issue.
>>>
>>> We have seen this before in JPRT Stockholm, which was the first JPRT system that had Windows 7.
>>>
>>> Current theory, not sure how much we understand this, is that the CYGWIN sshd service is somehow
>>> involved, and that if we manually start sshd the hang goes away.
>>> But so far we haven't had any solutions on how to get this manual sshd startup to work on reboots.
>>>
>>> I'll be taking all the Windows 7 systems out of the queues until we resolve this.
>>>
>>> -kto
>>>
>>> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>>>
>>>> It looks like some of new machines periodically timeout during jbb test run (>25min) so out jobs failed.
>>>>
>>>>  windows_x64-fastdebug-c2-jbb_default              FAILED(25m 40s)
>>>>        USED:     hostname=sc11136526 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>>>        ATTRS:    cygwin=true
>>>>        TIMING:   clean=1s init=13s work=25m12s fini=5s
>>>>        VMFLAGS:  -server -Djava.awt.headless=true
>>>>        NEEDS:    cygwin,gnumake381,jbb,jtreg
>>>>
>>>>
>>>>  windows_x64-fastdebug-c2-jbb_default              FAILED(25m 50s)
>>>>        USED:     hostname=sc11136603 platform=windows_x64_6.1 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true
>>>>        ATTRS:    mks=true
>>>>        TIMING:   clean=12s init=13s work=25m13s fini=4s
>>>>        VMFLAGS:  -server -Djava.awt.headless=true
>>>>        NEEDS:    gnumake381,jbb,jtreg,mks
>>>>
>>>> Vladimir
>>>>
>>>> Kelly O'Hair wrote:
>>>>> I have updated all the JPRT systems to a new version.
>>>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>>>> Changes:
>>>>> * hotspotwest will get all the Windows X64 machines currently used by the sfbay queue (4 X64 systems, 1 is a VM)
>>>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64 DevOp VMs
>>>>> * some changes with regards to how JPRT kills off processes on clients, should help kill off failed or hung cygwin builds
>>>>> * An attempt to allow ccache to work on Solaris with build-infra builds
>>>>> There are some JPRT sfbay machines that are down, tickets have been filed. So sfbay is shy Solaris SPARC and one MacPro.
>>>>> JPRT East is missing some Solaris SPARC machines.
>>>>> -kto
>>
> 

From john.coomes at oracle.com  Fri Oct 26 11:29:23 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Oct 2012 18:29:23 +0000
Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets
Message-ID: <20121026182932.310F447598@hg.openjdk.java.net>

Changeset: 685df3c6f84b
Author:    jmasa
Date:      2012-09-18 23:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/685df3c6f84b

7045397: NPG: Add freelists to class loader arenas.
Reviewed-by: coleenp, stefank, jprovino, ohair

! make/excludeSrc.make
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/binaryTreeDictionary.hpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeBlockDictionary.hpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/freeList.hpp
+ src/share/vm/memory/metablock.hpp
+ src/share/vm/memory/metachunk.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 476718ea6759
Author:    jmasa
Date:      2012-10-25 12:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/476718ea6759

8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk()
Reviewed-by: johnc, tamao

! src/share/vm/memory/binaryTreeDictionary.hpp

Changeset: b58313cf9afd
Author:    jcoomes
Date:      2012-10-26 08:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b58313cf9afd

Merge



From john.cuthbertson at oracle.com  Fri Oct 26 12:19:54 2012
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Fri, 26 Oct 2012 19:19:54 +0000
Subject: hg: hsx/hsx24/hotspot: 5 new changesets
Message-ID: <20121026192010.DC8C34759A@hg.openjdk.java.net>

Changeset: cb30646e4d38
Author:    brutisso
Date:      2012-09-17 10:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cb30646e4d38

7198130: G1: PrintReferenceGC output comes out of order
Summary: Move the first part of the GC logging, including timestamp, to the start of the GC
Reviewed-by: johnc, jwilhelm

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

Changeset: 3ef50622a632
Author:    johnc
Date:      2012-09-19 15:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3ef50622a632

7193946: Move warnings associated with UseMemSetInBOT flag
Summary: The warnings associated with the UseMemSetInBOT flag are duplicated in CMS and G1. The separate warnings have been removed and single instance of the warning has been placed in a common location.
Reviewed-by: brutisso, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 147a51fcb393
Author:    johnc
Date:      2012-09-20 09:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/147a51fcb393

7190666: G1: assert(_unused == 0) failed: Inconsistency in PLAB stats
Summary: Reset the fields in ParGCAllocBuffer, that are used for accumulating values for the ResizePLAB sensors in PLABStats, to zero after flushing the values to the PLABStats fields. Flush PLABStats values only when retiring the final allocation buffers prior to disposing of a G1ParScanThreadState object, rather than when retiring every allocation buffer.
Reviewed-by: jwilhelm, jmasa, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp

Changeset: 5560067e0f3c
Author:    johnc
Date:      2012-10-04 10:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5560067e0f3c

8000311: G1: ParallelGCThreads==0 broken
Summary: Divide by zero error, if ParallelGCThreads is 0, when adjusting the PLAB size.
Reviewed-by: jmasa, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp

Changeset: d41c4c86022a
Author:    johnc
Date:      2012-10-15 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d41c4c86022a

8000831: Heap verification output incorrect/incomplete
Summary: Restore non-silent output of heap verification.
Reviewed-by: ysr, brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/utilities/debug.cpp


From vladimir.kozlov at oracle.com  Fri Oct 26 16:03:44 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Fri, 26 Oct 2012 23:03:44 +0000
Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets
Message-ID: <20121026230406.D14C7475C0@hg.openjdk.java.net>

Changeset: cfe522e6461c
Author:    kvn
Date:      2012-10-17 12:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cfe522e6461c

8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space
Summary: Fix type of method pointer load from vtable.
Reviewed-by: twisti, johnc, roland

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

Changeset: e81a8af10cd9
Author:    kvn
Date:      2012-10-18 07:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e81a8af10cd9

8001071: Add simple range check into VM implemenation of Unsafe access methods
Summary: Add simple check in debug version of VM.
Reviewed-by: twisti, johnc

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

Changeset: aaeb9add1ab3
Author:    dlong
Date:      2012-10-19 14:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aaeb9add1ab3

8001101: C2: more general vector rule subsetting
Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms.
Reviewed-by: kvn, twisti
Contributed-by: dean.long at oracle.com

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

Changeset: 67f4c477c9ab
Author:    vlivanov
Date:      2012-10-22 11:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/67f4c477c9ab

8000805: JMM issue: short loads are non-atomic
Summary: perform transforms during IGVN phase when Load has a single user.
Reviewed-by: jrose, kvn, twisti

! src/share/vm/opto/mulnode.cpp
+ test/compiler/8000805/Test8000805.java

Changeset: fd1d564dd460
Author:    twisti
Date:      2012-10-22 16:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd1d564dd460

8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920)
Reviewed-by: kvn

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

Changeset: b2c669fd8114
Author:    kvn
Date:      2012-10-23 13:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b2c669fd8114

8001183: incorrect results of char vectors right shift operaiton
Summary: do vector right shift operation for small int types only after loads
Reviewed-by: jrose, dlong

! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! test/compiler/6340864/TestByteVect.java
! test/compiler/6340864/TestIntVect.java
! test/compiler/6340864/TestLongVect.java
! test/compiler/6340864/TestShortVect.java
+ test/compiler/8001183/TestCharVect.java

Changeset: a3ecd773a7b9
Author:    kvn
Date:      2012-10-24 14:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a3ecd773a7b9

7184394: add intrinsics to use AES instructions
Summary: Use new x86 AES instructions for AESCrypt.
Reviewed-by: twisti, kvn, roland
Contributed-by: tom.deneau at amd.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
+ test/compiler/7184394/TestAESBase.java
+ test/compiler/7184394/TestAESDecode.java
+ test/compiler/7184394/TestAESEncode.java
+ test/compiler/7184394/TestAESMain.java

Changeset: 006174cfe979
Author:    kvn
Date:      2012-10-25 17:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/006174cfe979

7163534: VM could crashes assert(false) failed: infinite EA connection graph build
Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already.
Reviewed-by: twisti

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/escape.cpp

Changeset: 410afdc6a07c
Author:    kvn
Date:      2012-10-26 11:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/410afdc6a07c

8001635: assert(in_bb(n)) failed: must be
Summary: Added missed check that Load node is in processed loop block.
Reviewed-by: twisti

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

Changeset: 588f08ed16cf
Author:    kvn
Date:      2012-10-26 12:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/588f08ed16cf

Merge

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


From david.holmes at oracle.com  Fri Oct 26 16:50:09 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 27 Oct 2012 09:50:09 +1000
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508A7C6E.7080802@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A75E5.2070100@oracle.com>
	<74CBB3F4-8707-4493-BAA7-9D22BEC9E2E4@oracle.com>
	<508A7C6E.7080802@oracle.com>
Message-ID: <508B21B1.3070805@oracle.com>

Coleen,

On 26/10/2012 10:05 PM, Coleen Phillimore wrote:
> On 10/26/2012 8:00 AM, Staffan Larsen wrote:
>> On 26 okt 2012, at 13:37, Coleen Phillimore
>> <coleen.phillimore at oracle.com> wrote:
>>
>>> Staffan, This looks really good.
>> Thanks.
>>
>>> Can you change the conditional now in arguments.cpp? Harold's checked
>>> in that change yesterday. Didn't know you'd get to this so fast. :) I
>>> guess it should be __APPLE__ now (idk).
>> I think it should still be _ALLBSD_SOURCE since the
>> UseLargePages-issue is true for the src/os/bsd files, not just when
>> compiled with __APPLE__.

The uses of _ALLBSD_SOURCE in the shared code are not affected by the 
eradication (I like that word!) from the BSD specific sources. Though as 
I suggested (too late) for Harold's change they can be hidden behind 
BSD_ONLY and NOT_BSD.

David


>
> Ok.
> thanks,
> Coleen
>>
>> /Staffan
>>
>>> A prize should go to someone who comes up with a better name for the
>>> posix directory and we should add common code there. Although it
>>> looks like os_bsd.cpp doesn't share as much with os_linux.cpp as
>>> hoped. I think we can't use 'unix'. How about 'ix'?
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 10/26/2012 6:47 AM, Staffan Larsen wrote:
>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>> define is always set when compiling these files it is not necessary
>>>> to use it in the source files. The usage was originally added during
>>>> the porting to make it easier to see changes against the base linux
>>>> version.
>>>>
>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>>
>>>> Thanks,
>>>> /Staffan
>

From alejandro.murillo at oracle.com  Fri Oct 26 16:50:09 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 26 Oct 2012 23:50:09 +0000
Subject: hg: hsx/hsx25/hotspot: 24 new changesets
Message-ID: <20121026235100.378C4475C3@hg.openjdk.java.net>

Changeset: 556dd9e475c6
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/556dd9e475c6

Added tag jdk8-b62 for changeset dccd40de8db1

! .hgtags

Changeset: d0e7716b179e
Author:    amurillo
Date:      2012-10-19 11:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d0e7716b179e

8001176: new hotspot build - hs25-b07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 85916677fc22
Author:    coleenp
Date:      2012-10-18 13:08 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/85916677fc22

7188233: UseVMInterruptibleIO flag deprecate for JDK8
Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8.  The flag will still enable Interruptible IO on Solaris, but users will get a warning.
Reviewed-by: dholmes, acorn, alanb
Contributed-by: harold.seigel at oracle.com

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

Changeset: 8ebcedb7604d
Author:    coleenp
Date:      2012-10-18 13:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8ebcedb7604d

7053130: hs_err file does not record specified CLASSPATH
Summary: Added code to write the value of the java.class.path property to the hs_err file.
Reviewed-by: kmo, dholmes, kvn
Contributed-by: harold.seigel at oracle.com

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

Changeset: c7957b458bf8
Author:    minqi
Date:      2012-10-19 08:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c7957b458bf8

8000818: SA constant pool need to reference to reference map after permgen removal
Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java

Changeset: 8eeffbc22f10
Author:    minqi
Date:      2012-10-19 08:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8eeffbc22f10

8001055: Bytes.swap should follow big endian
Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java

Changeset: 716c64bda5ba
Author:    zgu
Date:      2012-10-19 21:40 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/716c64bda5ba

7199092: NMT: NMT needs to deal overlapped virtual memory ranges
Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map.
Reviewed-by: acorn, coleenp

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/handles.inline.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/memBaseline.cpp
! src/share/vm/services/memBaseline.hpp
! src/share/vm/services/memPtr.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memRecorder.cpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memReporter.cpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memSnapshot.cpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: b988bff99b38
Author:    zgu
Date:      2012-10-19 18:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b988bff99b38

Merge


Changeset: 80f44792c0c9
Author:    coleenp
Date:      2012-10-22 12:01 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/80f44792c0c9

Merge


Changeset: 685df3c6f84b
Author:    jmasa
Date:      2012-09-18 23:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/685df3c6f84b

7045397: NPG: Add freelists to class loader arenas.
Reviewed-by: coleenp, stefank, jprovino, ohair

! make/excludeSrc.make
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/binaryTreeDictionary.hpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeBlockDictionary.hpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/freeList.hpp
+ src/share/vm/memory/metablock.hpp
+ src/share/vm/memory/metachunk.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 476718ea6759
Author:    jmasa
Date:      2012-10-25 12:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/476718ea6759

8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk()
Reviewed-by: johnc, tamao

! src/share/vm/memory/binaryTreeDictionary.hpp

Changeset: b58313cf9afd
Author:    jcoomes
Date:      2012-10-26 08:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b58313cf9afd

Merge


Changeset: cfe522e6461c
Author:    kvn
Date:      2012-10-17 12:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cfe522e6461c

8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space
Summary: Fix type of method pointer load from vtable.
Reviewed-by: twisti, johnc, roland

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

Changeset: e81a8af10cd9
Author:    kvn
Date:      2012-10-18 07:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e81a8af10cd9

8001071: Add simple range check into VM implemenation of Unsafe access methods
Summary: Add simple check in debug version of VM.
Reviewed-by: twisti, johnc

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

Changeset: aaeb9add1ab3
Author:    dlong
Date:      2012-10-19 14:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aaeb9add1ab3

8001101: C2: more general vector rule subsetting
Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms.
Reviewed-by: kvn, twisti
Contributed-by: dean.long at oracle.com

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

Changeset: 67f4c477c9ab
Author:    vlivanov
Date:      2012-10-22 11:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/67f4c477c9ab

8000805: JMM issue: short loads are non-atomic
Summary: perform transforms during IGVN phase when Load has a single user.
Reviewed-by: jrose, kvn, twisti

! src/share/vm/opto/mulnode.cpp
+ test/compiler/8000805/Test8000805.java

Changeset: fd1d564dd460
Author:    twisti
Date:      2012-10-22 16:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fd1d564dd460

8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920)
Reviewed-by: kvn

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

Changeset: b2c669fd8114
Author:    kvn
Date:      2012-10-23 13:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b2c669fd8114

8001183: incorrect results of char vectors right shift operaiton
Summary: do vector right shift operation for small int types only after loads
Reviewed-by: jrose, dlong

! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! test/compiler/6340864/TestByteVect.java
! test/compiler/6340864/TestIntVect.java
! test/compiler/6340864/TestLongVect.java
! test/compiler/6340864/TestShortVect.java
+ test/compiler/8001183/TestCharVect.java

Changeset: a3ecd773a7b9
Author:    kvn
Date:      2012-10-24 14:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a3ecd773a7b9

7184394: add intrinsics to use AES instructions
Summary: Use new x86 AES instructions for AESCrypt.
Reviewed-by: twisti, kvn, roland
Contributed-by: tom.deneau at amd.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
+ test/compiler/7184394/TestAESBase.java
+ test/compiler/7184394/TestAESDecode.java
+ test/compiler/7184394/TestAESEncode.java
+ test/compiler/7184394/TestAESMain.java

Changeset: 006174cfe979
Author:    kvn
Date:      2012-10-25 17:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/006174cfe979

7163534: VM could crashes assert(false) failed: infinite EA connection graph build
Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already.
Reviewed-by: twisti

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/escape.cpp

Changeset: 410afdc6a07c
Author:    kvn
Date:      2012-10-26 11:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/410afdc6a07c

8001635: assert(in_bb(n)) failed: must be
Summary: Added missed check that Load node is in processed loop block.
Reviewed-by: twisti

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

Changeset: 588f08ed16cf
Author:    kvn
Date:      2012-10-26 12:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/588f08ed16cf

Merge

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

Changeset: dc16fe422c53
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dc16fe422c53

Merge


Changeset: 57c61f87a1fd
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/57c61f87a1fd

Added tag hs25-b07 for changeset dc16fe422c53

! .hgtags


From jiangli.zhou at oracle.com  Fri Oct 26 16:52:02 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 26 Oct 2012 16:52:02 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <508AC578.2000603@oracle.com>
References: <5089C7E1.2040206@oracle.com> <508A4CD4.2090009@oracle.com>
	<508AC578.2000603@oracle.com>
Message-ID: <508B2222.4070603@oracle.com>

Hi Alan,

I tried a few experiments with the makefiles. Looks like 
jdk/make/java/invoke/Makefile is not the right place to set the 
-timeoutFactor option. I'm reluctant to set a large timeoutFactor in 
jdk/test/Makefile. Some of the java.lang.invoke jtreg test take long 
time to run. For example, the test.java.lang.invoke.MethodHandlesTest 
takes about 1.5 hour to run on certain devices. Since there are only 3~4 
java.lang.invoke tests have the timeout issue and each of them has very 
different execution duration, I'm inclined to set each specific timeout 
value for different test. Please let me know your opinion.

Thanks,
Jiangli


On 10/26/2012 10:16 AM, Jiangli Zhou wrote:
> Hi Alan,
>
> Thanks for bring up the -timeoutFactor option. I was told about the 
> option but didn't go that way. Looking at the jdk/make directory now, 
> there are individual Makefile under each test directory (wasn't aware 
> that earlier). If we can just control the java/lang/invoke tests 
> timeout factor by adding the option in  jdk/make/java/invoke/Makefile, 
> that seems to be a better way than changing individual test as there 
> are multiple tests in the category times out.
>
> Thanks,
>
> Jiangli
>
> On 10/26/2012 01:41 AM, Alan Bateman wrote:
>> On 26/10/2012 00:14, Jiangli Zhou wrote:
>>> Hi,
>>>
>>> Please review the timeout change to 
>>> test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes 
>>> longer time to execute on certain embedded devices. It takes about 
>>> 23 minutes to run on an ARM softfloat device with fastdebug binary. 
>>> Using a 2000s timeout here just to be sure.
>>>
>>>   http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
>>>
>>> Thanks,
>>> Jiangli
>>>
>> You might know this already but the jtreg -timeoutFactor option can 
>> be used to apply a scaling factor to the timeout. This may not be 
>> fine grained enough to only increase it for tests that are floating 
>> point intensive but it is generally useful to use this when running 
>> tests on slow machines. The downside is that it increases the overall 
>> execution time when there are tests that fail due to reaching the 
>> timeout (but such tests could be added to the exclude list to avoid 
>> running them).
>>
>> -Alan
>


From david.holmes at oracle.com  Fri Oct 26 16:59:20 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 27 Oct 2012 09:59:20 +1000
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>
Message-ID: <508B23D8.2@oracle.com>

On 26/10/2012 10:03 PM, Staffan Larsen wrote:
> Oh... and new webrev at: http://cr.openjdk.java.net/~sla/8001619/webrev.01/

Thumbs up.

But for completeness I would have liked to see the zero code cleaned up 
too. I'm not sure how the contact is. I'm tempted to say do it anyway as 
it seems simple enough and if it happens to break zero someone will 
shout and we do a fix. Otherwise the chances that this cleanup will get 
applied to the zero code seem very low.

David

>
> On 26 okt 2012, at 13:58, Staffan Larsen <staffan.larsen at oracle.com
> <mailto:staffan.larsen at oracle.com>> wrote:
>
>>
>> On 26 okt 2012, at 13:35, David Holmes <David.Holmes at oracle.com
>> <mailto:David.Holmes at oracle.com>> wrote:
>>
>>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>> define is always set when compiling these files it is not necessary
>>>> to use it in the source files. The usage was originally added during
>>>> the porting to make it easier to see changes against the base linux
>>>> version.
>>>>
>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>
>>> Generally looks okay (though now I see some of the actual BSD code it
>>> makes me a little nervous!). A couple of minor things:
>>
>> Thanks.
>>
>>>
>>> os_bsd.cpp:
>>>
>>> 977 }
>>> 978 #elif
>>>
>>> 3957 return true;
>>> 3958 #elif
>>> 3959 return false;
>>>
>>> Shouldn't the elif's have become an else?
>>>
>>> Ditto for os_bsd_x86.cpp:
>>>
>>> 850 #elif
>>
>> You are right. I've fixed this.
>>
>>> Also you can probably do the same thing for bsd_zero:
>>> /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.
>>
>> I didn't touch the zero files since I wasn't sure who maintains it.
>> I'm not sure how to build it so I didn't want to do changes.
>>
>> /Staffan
>>
>>
>>>
>>> David
>>> -----
>>>
>>>> Thanks,
>>>> /Staffan
>>
>

From vladimir.kozlov at oracle.com  Fri Oct 26 18:29:25 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Sat, 27 Oct 2012 01:29:25 +0000
Subject: hg: hsx/hsx24/hotspot: 33 new changesets
Message-ID: <20121027013035.EF639475C9@hg.openjdk.java.net>

Changeset: 86ff8343397f
Author:    twisti
Date:      2012-09-10 16:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/86ff8343397f

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

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

Changeset: 3e4ba5ce9f62
Author:    twisti
Date:      2012-09-17 12:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3e4ba5ce9f62

7196262: JSR 292: java/lang/invoke/PrivateInvokeTest.java fails on solaris-sparc
Reviewed-by: kvn, jrose, bdelsart

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/asm/register.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 41e38d0c2775
Author:    kvn
Date:      2012-09-17 17:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/41e38d0c2775

7197033: missing ResourceMark for assert in Method::bci_from()
Summary: Added missing ResourceMark.
Reviewed-by: dholmes, coleenp, jmasa

! src/share/vm/oops/methodOop.cpp

Changeset: 3b9a69e318e6
Author:    kvn
Date:      2012-09-17 19:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3b9a69e318e6

7196199: java/text/Bidi/Bug6665028.java failed: Bidi run count incorrect
Summary: Save whole XMM/YMM registers in safepoint interrupt handler.
Reviewed-by: roland, twisti

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/x86.ad
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
+ test/compiler/7196199/Test7196199.java

Changeset: 963f87017a47
Author:    twisti
Date:      2012-09-19 10:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/963f87017a47

7198499: TraceTypeProfile as diagnostic option
Reviewed-by: kvn
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/doCall.cpp

Changeset: 5db5d32645cc
Author:    kvn
Date:      2012-09-19 16:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5db5d32645cc

7199010: incorrect vector alignment
Summary: Fixed vectors alignment when several arrays are accessed in one loop.
Reviewed-by: roland, twisti

! src/cpu/x86/vm/vm_version_x86.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp

Changeset: 33582180c45d
Author:    roland
Date:      2012-09-20 16:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/33582180c45d

7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement()
Summary: use shorter instruction sequences for atomic add and atomic exchange when possible.
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/x86.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/escape.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp

Changeset: 4964b154f3dc
Author:    kvn
Date:      2012-09-24 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4964b154f3dc

7200163: add CodeComments functionality to assember stubs
Summary: Pass the codeBuffer to the Stub constructor, and adapts the disassembler to print the comments.
Reviewed-by: jrose, kvn, twisti
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/icBuffer.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/stubs.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/disassembler.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 555941c3105e
Author:    twisti
Date:      2012-09-24 11:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/555941c3105e

7188176: The JVM should differentiate between T and M series and adjust GC ergonomics
Reviewed-by: kvn
Contributed-by: Tao Mao <tao.mao at oracle.com>

! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vm_version_sparc.hpp

Changeset: 4e1f60696a85
Author:    twisti
Date:      2012-09-24 17:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4e1f60696a85

7200001: failed C1 OSR compile doesn't get recompiled with C2
Reviewed-by: kvn

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/accessFlags.hpp

Changeset: d6c51404777e
Author:    neliasso
Date:      2012-03-29 16:43 +0200
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d6c51404777e

7163863: Updated projectcreator
Summary: Enable source browsing for all platform dependent code
Reviewed-by: brutisso, coleenp

! make/windows/makefiles/projectcreator.make
! src/share/tools/ProjectCreator/BuildConfig.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
+ src/share/tools/ProjectCreator/FileTreeCreator.java
+ src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
+ src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/Util.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java

Changeset: 87e8474b098a
Author:    kvn
Date:      2012-09-25 10:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/87e8474b098a

7200233: C2: can't use expand rules for vector instruction rules
Summary: Added missed _bottom_type set in ArchDesc::defineExpand() and missed vector nodes in MatchRule::is_vector().
Reviewed-by: twisti, roland, dlong

! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: c2cd6435d1d3
Author:    kvn
Date:      2012-09-25 15:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c2cd6435d1d3

7200264: 7192963 changes disabled shift vectors
Summary: Replaced is_vector_use() call with explicit check for vector shift's count.
Reviewed-by: twisti, roland, dlong, vlivanov

! src/share/vm/opto/superword.cpp
+ test/compiler/7200264/Test7200264.sh
+ test/compiler/7200264/TestIntVect.java

Changeset: 08d35f1d0bf5
Author:    kvn
Date:      2012-09-27 09:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/08d35f1d0bf5

7193318: C2: remove number of inputs requirement from Node's new operator
Summary: Deleted placement new operator of Node - node(size_t, Compile *, int).
Reviewed-by: kvn, twisti
Contributed-by: bharadwaj.yadavalli at oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/divnode.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/mulnode.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/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp

Changeset: 1f42fbfc3337
Author:    kvn
Date:      2012-09-27 15:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1f42fbfc3337

7198084: NPG: distance is too big for short branches in test_invocation_counter_for_mdp()
Summary: use long branches in test_invocation_counter_for_mdp()
Reviewed-by: twisti

! src/cpu/sparc/vm/interp_masm_sparc.cpp

Changeset: 14ca810d935b
Author:    kvn
Date:      2012-10-02 12:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/14ca810d935b

7201026: add vector for shift count
Summary: Add generation of vectors for scalar shift count.
Reviewed-by: roland, twisti, dlong

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
! test/compiler/7200264/Test7200264.sh

Changeset: 98191f9d491f
Author:    kvn
Date:      2012-10-02 14:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/98191f9d491f

7199742: A lot of C2 OSR compilations of the same method's bci
Summary: Don't clone head of OSR loop.
Reviewed-by: jrose, twisti

! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/opto/parse1.cpp
+ test/compiler/7199742/Test7199742.java

Changeset: 5c6a5b30734b
Author:    neliasso
Date:      2012-10-04 06:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5c6a5b30734b

8000102: Resolve include conflicts
Summary: Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files.
Reviewed-by: kvn
Contributed-by: nils.eliasson at oracle.com

! 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/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.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

Changeset: 6d47cfd567eb
Author:    vlivanov
Date:      2012-10-05 18:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6d47cfd567eb

7177003: C1: LogCompilation support
Summary: add LogCompilation support in C1 - both client and tiered mode.
Reviewed-by: twisti, kvn

! src/os/linux/vm/vmError_linux.cpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compileLog.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/ostream.cpp

Changeset: c64eebdc1199
Author:    vlivanov
Date:      2012-10-05 19:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c64eebdc1199

8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64
Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore.
Reviewed-by: twisti, kvn

! src/share/vm/code/dependencies.cpp

Changeset: 85fb3ddfd7d9
Author:    vlivanov
Date:      2012-10-05 19:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/85fb3ddfd7d9

8000485: Hotspot build fails in Solaris Studio IDE when building dtrace
Summary: Prepend '.' to the existing native library path
Reviewed-by: kvn, sspitsyn

! make/bsd/makefiles/dtrace.make
! make/solaris/makefiles/dtrace.make

Changeset: 42337887af88
Author:    vlivanov
Date:      2012-10-08 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/42337887af88

8000313: C2 should use jlong for 64bit values
Summary: Replace all occurrences of long with jlong in C2 code.
Reviewed-by: kvn, twisti

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

Changeset: 20ad80ad4c86
Author:    twisti
Date:      2012-10-08 17:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/20ad80ad4c86

8000263: JSR 292: signature types may appear to be unloaded
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 5e5e4af32a80
Author:    vlivanov
Date:      2012-10-09 12:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5e5e4af32a80

7199654: Remove LoadUI2LNode
Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead.
Reviewed-by: kvn

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/superword.cpp

Changeset: 5c8384700293
Author:    kvn
Date:      2012-10-09 16:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5c8384700293

8000592: Improve adlc usability
Summary: several changes to adlc to improve its usability
Reviewed-by: kvn
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/archDesc.hpp
! src/share/vm/adlc/dict2.cpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/main.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: cc602d511176
Author:    twisti
Date:      2012-10-11 14:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cc602d511176

8000740: remove LinkWellKnownClasses
Reviewed-by: kvn, jrose

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

Changeset: 914513a8194f
Author:    kvn
Date:      2012-10-18 07:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/914513a8194f

8001071: Add simple range check into VM implemenation of Unsafe access methods
Summary: Add simple check in debug version of VM.
Reviewed-by: twisti, johnc

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

Changeset: 2728933b6d93
Author:    dlong
Date:      2012-10-19 14:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2728933b6d93

8001101: C2: more general vector rule subsetting
Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms.
Reviewed-by: kvn, twisti
Contributed-by: dean.long at oracle.com

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

Changeset: 8dcd5a1c0f23
Author:    vlivanov
Date:      2012-10-22 11:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8dcd5a1c0f23

8000805: JMM issue: short loads are non-atomic
Summary: perform transforms during IGVN phase when Load has a single user.
Reviewed-by: jrose, kvn, twisti

! src/share/vm/opto/mulnode.cpp
+ test/compiler/8000805/Test8000805.java

Changeset: 0e68d290c3f9
Author:    twisti
Date:      2012-10-22 16:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0e68d290c3f9

8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920)
Reviewed-by: kvn

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

Changeset: cca5d281e05c
Author:    kvn
Date:      2012-10-23 13:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cca5d281e05c

8001183: incorrect results of char vectors right shift operaiton
Summary: do vector right shift operation for small int types only after loads
Reviewed-by: jrose, dlong

! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! test/compiler/6340864/TestByteVect.java
! test/compiler/6340864/TestIntVect.java
! test/compiler/6340864/TestLongVect.java
! test/compiler/6340864/TestShortVect.java
+ test/compiler/8001183/TestCharVect.java

Changeset: 6a1d4ebcda4b
Author:    kvn
Date:      2012-10-25 17:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6a1d4ebcda4b

7163534: VM could crashes assert(false) failed: infinite EA connection graph build
Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already.
Reviewed-by: twisti

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/escape.cpp

Changeset: b0556586212c
Author:    kvn
Date:      2012-10-26 11:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b0556586212c

8001635: assert(in_bb(n)) failed: must be
Summary: Added missed check that Load node is in processed loop block.
Reviewed-by: twisti

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


From alejandro.murillo at oracle.com  Fri Oct 26 19:36:54 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 27 Oct 2012 02:36:54 +0000
Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets
Message-ID: <20121027023705.5DCF3475CB@hg.openjdk.java.net>

Changeset: 556dd9e475c6
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/556dd9e475c6

Added tag jdk8-b62 for changeset dccd40de8db1

! .hgtags

Changeset: dc16fe422c53
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dc16fe422c53

Merge


Changeset: 57c61f87a1fd
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/57c61f87a1fd

Added tag hs25-b07 for changeset dc16fe422c53

! .hgtags

Changeset: a516debe2cee
Author:    amurillo
Date:      2012-10-26 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a516debe2cee

8001663: new hotspot build - hs25-b08
Reviewed-by: jcoomes

! make/hotspot_version


From david.holmes at oracle.com  Sat Oct 27 01:04:37 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 27 Oct 2012 18:04:37 +1000
Subject: JPRT system changes
In-Reply-To: <508AD658.5070102@oracle.com>
References: <5A0CE850-9184-48FC-B158-43EE61324046@oracle.com>	<185B1455-0F13-493C-8655-33E2C87DD074@oracle.com>	<508ABAD4.6040400@oracle.com>	<BE47A932-026D-4885-B525-24A7F849EFCC@oracle.com>	<508AC500.10801@oracle.com>
	<477AAC1D-CF92-4504-B83B-23EBD6CC108B@oracle.com>
	<508AD658.5070102@oracle.com>
Message-ID: <508B9595.8040502@oracle.com>

So correct me if I'm wrong but all this stems from making jbb run in 
headless mode - right? Which was only done to fix macs - right? If so 
then it seems to me that the shorter path may be running headless on mac 
only ?

David

On 27/10/2012 4:28 AM, Vladimir Kozlov wrote:
>  > I think it's all jbb variations, not just jbb_default, right?
>
> I saw it failed only with fastdebug VM and we run only default version
> on Win64:
>
> ${jprt.my.windows.x64}-{product|fastdebug}-c2-jbb_default, \
> ${jprt.my.windows.x64}-{product|fastdebug}-c2-jbb_default_nontiered, \
>
> Vladimir
>
> Kelly O'Hair wrote:
>> On Oct 26, 2012, at 10:14 AM, Tim Bell wrote:
>>
>>> Adding hotspot-dev for the question about jbb_default below.
>>>
>>> Kelly-
>>>
>>>> I'll be taking all the Windows 7 systems out of the queues until we
>>>> resolve this.
>>> Rather than take them out, could you make thw W7 systems build-only?
>>
>> We could do that, but I had hopes we had a solution that we could
>> deploy and bury this issue for good.
>>
>>> The root of the problem is that jbb does not really run properly in
>>> headless mode. Everything after that has been us standing on our
>>> heads trying to work around breakage in jbb or in AWT.
>>
>> Yeah, this is annoying.
>>
>>> Is jbb_default worth keeping, or is it simply run out of habit? Just
>>> asking because it is causing a fair amount of trouble.
>>
>> I think it's all jbb variations, not just jbb_default, right?
>>
>> -kto
>>
>>>
>>> Tim
>>>
>>> On 10/26/12 09:56, Kelly O'Hair wrote:
>>>> It's the Windows 7 jbb issue.
>>>>
>>>> We have seen this before in JPRT Stockholm, which was the first JPRT
>>>> system that had Windows 7.
>>>>
>>>> Current theory, not sure how much we understand this, is that the
>>>> CYGWIN sshd service is somehow
>>>> involved, and that if we manually start sshd the hang goes away.
>>>> But so far we haven't had any solutions on how to get this manual
>>>> sshd startup to work on reboots.
>>>>
>>>> I'll be taking all the Windows 7 systems out of the queues until we
>>>> resolve this.
>>>>
>>>> -kto
>>>>
>>>> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>>>>
>>>>> It looks like some of new machines periodically timeout during jbb
>>>>> test run (>25min) so out jobs failed.
>>>>>
>>>>> windows_x64-fastdebug-c2-jbb_default FAILED(25m 40s)
>>>>> USED: hostname=sc11136526 platform=windows_x64_6.1 osname=windows
>>>>> osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1
>>>>> compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true
>>>>> pstools=true
>>>>> ATTRS: cygwin=true
>>>>> TIMING: clean=1s init=13s work=25m12s fini=5s
>>>>> VMFLAGS: -server -Djava.awt.headless=true
>>>>> NEEDS: cygwin,gnumake381,jbb,jtreg
>>>>>
>>>>>
>>>>> windows_x64-fastdebug-c2-jbb_default FAILED(25m 50s)
>>>>> USED: hostname=sc11136603 platform=windows_x64_6.1 osname=windows
>>>>> osarch=x64 cpus=2 parallelcount=2 ram=7899MB instance=P1
>>>>> compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true
>>>>> pstools=true
>>>>> ATTRS: mks=true
>>>>> TIMING: clean=12s init=13s work=25m13s fini=4s
>>>>> VMFLAGS: -server -Djava.awt.headless=true
>>>>> NEEDS: gnumake381,jbb,jtreg,mks
>>>>>
>>>>> Vladimir
>>>>>
>>>>> Kelly O'Hair wrote:
>>>>>> I have updated all the JPRT systems to a new version.
>>>>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>>>>> Changes:
>>>>>> * hotspotwest will get all the Windows X64 machines currently used
>>>>>> by the sfbay queue (4 X64 systems, 1 is a VM)
>>>>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>>>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64
>>>>>> DevOp VMs
>>>>>> * some changes with regards to how JPRT kills off processes on
>>>>>> clients, should help kill off failed or hung cygwin builds
>>>>>> * An attempt to allow ccache to work on Solaris with build-infra
>>>>>> builds
>>>>>> There are some JPRT sfbay machines that are down, tickets have
>>>>>> been filed. So sfbay is shy Solaris SPARC and one MacPro.
>>>>>> JPRT East is missing some Solaris SPARC machines.
>>>>>> -kto
>>>
>>

From Alan.Bateman at oracle.com  Sun Oct 28 06:59:19 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Oct 2012 13:59:19 +0000
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <508B2222.4070603@oracle.com>
References: <5089C7E1.2040206@oracle.com> <508A4CD4.2090009@oracle.com>
	<508AC578.2000603@oracle.com> <508B2222.4070603@oracle.com>
Message-ID: <508D3A37.7060600@oracle.com>

On 27/10/2012 00:52, Jiangli Zhou wrote:
> Hi Alan,
>
> I tried a few experiments with the makefiles. Looks like 
> jdk/make/java/invoke/Makefile is not the right place to set the 
> -timeoutFactor option. I'm reluctant to set a large timeoutFactor in 
> jdk/test/Makefile. Some of the java.lang.invoke jtreg test take long 
> time to run. For example, the test.java.lang.invoke.MethodHandlesTest 
> takes about 1.5 hour to run on certain devices. Since there are only 
> 3~4 java.lang.invoke tests have the timeout issue and each of them has 
> very different execution duration, I'm inclined to set each specific 
> timeout value for different test. Please let me know your opinion.
>
> Thanks,
> Jiangli
>
If you are running the tests via the make file then this should work:

make EXTRA_JTREG_OPTIONS=-timeoutFactor:10 jdk_lang

but I see that the Makefile puts its own defaults, 
including-timeoutFactor:4, after the options set via 
EXTRA_JTREG_OPTIONS. That plus jtreg doesn't allow the -timeoutFactor to 
be specified more than once on the command line. Minimally we should fix 
the make file so that options specified via EXTRA_JTREG_OPTIONS override 
any defaults in the make file.

I think you'll need to check with Christian or John as to whether they 
would object to have very high timeouts on these tests. Personally I 
think it should be possible to specify a timeout scaling factor when 
running the tests rather than having each test specify a /timeout for 
the slowest possible machine that the test might run on.

-Alan.





From chris.plummer at oracle.com  Sun Oct 28 14:44:49 2012
From: chris.plummer at oracle.com (Chris Plummer)
Date: Sun, 28 Oct 2012 14:44:49 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <mailman.3.1351450800.846.hotspot-dev@openjdk.java.net>
References: <mailman.3.1351450800.846.hotspot-dev@openjdk.java.net>
Message-ID: <508DA751.3000307@oracle.com>

On 10/28/12 12:00 PM, hotspot-dev-request at openjdk.java.net wrote:
> On 27/10/2012 00:52, Jiangli Zhou wrote:
>> >Hi Alan,
>> >
>> >I tried a few experiments with the makefiles. Looks like
>> >jdk/make/java/invoke/Makefile is not the right place to set the
>> >-timeoutFactor option. I'm reluctant to set a large timeoutFactor in
>> >jdk/test/Makefile. Some of the java.lang.invoke jtreg test take long
>> >time to run. For example, the test.java.lang.invoke.MethodHandlesTest
>> >takes about 1.5 hour to run on certain devices. Since there are only
>> >3~4 java.lang.invoke tests have the timeout issue and each of them has
>> >very different execution duration, I'm inclined to set each specific
>> >timeout value for different test. Please let me know your opinion.
>> >
>> >Thanks,
>> >Jiangli
>> >
> If you are running the tests via the make file then this should work:
>
> make EXTRA_JTREG_OPTIONS=-timeoutFactor:10 jdk_lang
>
> but I see that the Makefile puts its own defaults,
> including-timeoutFactor:4, after the options set via
> EXTRA_JTREG_OPTIONS. That plus jtreg doesn't allow the -timeoutFactor to
> be specified more than once on the command line. Minimally we should fix
> the make file so that options specified via EXTRA_JTREG_OPTIONS override
> any defaults in the make file.
>
> I think you'll need to check with Christian or John as to whether they
> would object to have very high timeouts on these tests. Personally I
> think it should be possible to specify a timeout scaling factor when
> running the tests rather than having each test specify a /timeout for
> the slowest possible machine that the test might run on.
>
> -Alan.
It seems we need a combination of both. Longer tests need a scaling 
factor, as do slower devices. They should both be combined to make sure 
the longer running tests will complete on the slower devices. I think 
the "timeout" value in the test serves the former, and the jtreg 
-timeoutFactor option serves the later. However, I'm not sure if SQE is 
using -timeoutFactor for the slower devices. If they are not, then we 
should ask that they start using it. It might save the need to add or 
increase the "timeout" for many tests. For CallSiteTest.java, since it 
is a long running test, it should have a timeout added to it.

I don't see we would ever want to specify -timeoutFactor in a makefile 
when it will be equally applied to all tests and all devices. This 
requires it be set in such a way that the longest running test will 
complete on the slowest device. This will cause valid timeouts to take 
too long to happen on faster devices and short running tests.

Chris

From bharadwaj.yadavalli at oracle.com  Sun Oct 28 20:12:23 2012
From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli)
Date: Sun, 28 Oct 2012 23:12:23 -0400
Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of
	dead nodes
Message-ID: <508DF417.7090906@oracle.com>

I'd like to get a code review of the changes at 
http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_01/

These changes are made to keep an (almost) accurate running count of the 
reachable (live) flow graph nodes. This will result in a more realistic 
node count for various phases of C2 to decide on whether to proceed with 
optimizations or not. Prior to these changes, C2 bails out of 
compilation based on the number of nodes created which typically larger 
than the number of reachable (live) nodes.

I observed no significant degradation in C2 compilation time of all 
classes in rt.jar time due to these changes.

Thanks,

Bharadwaj


From david.holmes at oracle.com  Sun Oct 28 22:15:03 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 Oct 2012 15:15:03 +1000
Subject: Default methods for jdk8: request for code review
In-Reply-To: <3BCECE5D-8B12-4B10-B2BE-E2F3B1001FD9@oracle.com>
References: <5075AC78.3030702@oracle.com> <508A96C6.1080207@oracle.com>
	<3BCECE5D-8B12-4B10-B2BE-E2F3B1001FD9@oracle.com>
Message-ID: <508E10D7.7070404@oracle.com>

Hi Keith,

The more I look at this the more questions that come to mind. :)

Can you expand on the rationale for using overpass methods instead of 
augmenting the existing method lookup procedures. I'm concerned about 
its impact on startup time - and given that we have not yet added all 
the default methods that will be added, nor do we know for certain which 
interfaces will get what methods, I don't think we can measure this yet.

In LinkResolver::resolve_method we would previously bail out if the 
resolved_klass is in fact an interface. But now we will pass that 
interface to both lookup_method_in_klasses and 
lookup_method_in_interfaces. That sounds wrong - should the names of 
these methods be updated?

In instanceKlass.cpp in the new interface initialization section why do 
you refer to the "superclass initialization error"? Are we simply 
pretending that any failure here was actually a superclass failure? And 
if so, is that temporary?

Thanks,
David


On 27/10/2012 1:07 AM, Keith McGuigan wrote:
>
> Thanks, Coleen,
>
> I need just one more reviewer.  If someone has time, here is the code and design/impl overview:
>
> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
> http://cr.openjdk.java.net/~kamg/default_methods/
>
> --
> - Keith
>
>
> On Oct 26, 2012, at 9:57 AM, Coleen Phillimore wrote:
>
>>
>> Hi,
>> I have read through all of this code.  Offline to Keith, I have suggested some name changes and comments to make it clearer, at least to me, what this code is doing.  It's very dense but I believe it is correct and finds the correct default method to add to the vtable in the most efficient way possible.
>> Keith, can you elaborate on the tests that you've run against this?
>> Thanks,
>> Coleen
>>
>> On 10/10/2012 1:12 PM, Keith McGuigan wrote:
>>> Hello,
>>>
>>> I'd like any review of the code which implements default methods in the JVM.  This is destined for jdk8 as part of JSR 335 (Lambdas), and tracked by CR 7200776.
>>>
>>> The design and implementation is described in this short document:
>>> http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt
>>>
>>> And the code is here:
>>> http://cr.openjdk.java.net/~kamg/default_methods/
>>>
>>> Any review (even partial) would be appreciated.  Thanks!
>>>
>>> --
>>> - Keith
>

From staffan.larsen at oracle.com  Mon Oct 29 02:30:45 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 29 Oct 2012 10:30:45 +0100
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508B23D8.2@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>
	<508B23D8.2@oracle.com>
Message-ID: <A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>

Here's a version with the zero changes as well: http://cr.openjdk.java.net/~sla/8001619/webrev.02/

If it looks good, I'll push this version instead.

/Staffan

On 27 okt 2012, at 01:59, David Holmes <David.Holmes at oracle.com> wrote:

> On 26/10/2012 10:03 PM, Staffan Larsen wrote:
>> Oh... and new webrev at: http://cr.openjdk.java.net/~sla/8001619/webrev.01/
> 
> Thumbs up.
> 
> But for completeness I would have liked to see the zero code cleaned up too. I'm not sure how the contact is. I'm tempted to say do it anyway as it seems simple enough and if it happens to break zero someone will shout and we do a fix. Otherwise the chances that this cleanup will get applied to the zero code seem very low.
> 
> David
> 
>> 
>> On 26 okt 2012, at 13:58, Staffan Larsen <staffan.larsen at oracle.com
>> <mailto:staffan.larsen at oracle.com>> wrote:
>> 
>>> 
>>> On 26 okt 2012, at 13:35, David Holmes <David.Holmes at oracle.com
>>> <mailto:David.Holmes at oracle.com>> wrote:
>>> 
>>>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>>> define is always set when compiling these files it is not necessary
>>>>> to use it in the source files. The usage was originally added during
>>>>> the porting to make it easier to see changes against the base linux
>>>>> version.
>>>>> 
>>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>> 
>>>> Generally looks okay (though now I see some of the actual BSD code it
>>>> makes me a little nervous!). A couple of minor things:
>>> 
>>> Thanks.
>>> 
>>>> 
>>>> os_bsd.cpp:
>>>> 
>>>> 977 }
>>>> 978 #elif
>>>> 
>>>> 3957 return true;
>>>> 3958 #elif
>>>> 3959 return false;
>>>> 
>>>> Shouldn't the elif's have become an else?
>>>> 
>>>> Ditto for os_bsd_x86.cpp:
>>>> 
>>>> 850 #elif
>>> 
>>> You are right. I've fixed this.
>>> 
>>>> Also you can probably do the same thing for bsd_zero:
>>>> /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.
>>> 
>>> I didn't touch the zero files since I wasn't sure who maintains it.
>>> I'm not sure how to build it so I didn't want to do changes.
>>> 
>>> /Staffan
>>> 
>>> 
>>>> 
>>>> David
>>>> -----
>>>> 
>>>>> Thanks,
>>>>> /Staffan
>>> 
>> 


From david.holmes at oracle.com  Mon Oct 29 04:23:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 Oct 2012 21:23:40 +1000
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>
	<508B23D8.2@oracle.com>
	<A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
Message-ID: <508E673C.30902@oracle.com>

On 29/10/2012 7:30 PM, Staffan Larsen wrote:
> Here's a version with the zero changes as well: http://cr.openjdk.java.net/~sla/8001619/webrev.02/
>
> If it looks good, I'll push this version instead.

Some of the conditionals are puzzling to me given this was all done for 
the MacOSX port:

  326 #ifdef __APPLE__
  ...
  331 #elif defined(__OpenBSD__)
  ...
  342 #elif defined(_ALLBSD_SOURCE)
  ...

I would have expected __APPLE__ to always be defined (else it is 
redundant everywhere else!), but then that would preclude the 
_ALLBSD_SOURCE code from being used.

Maybe it is best to leave this after all - sorry :(

David



> /Staffan
>
> On 27 okt 2012, at 01:59, David Holmes<David.Holmes at oracle.com>  wrote:
>
>> On 26/10/2012 10:03 PM, Staffan Larsen wrote:
>>> Oh... and new webrev at: http://cr.openjdk.java.net/~sla/8001619/webrev.01/
>>
>> Thumbs up.
>>
>> But for completeness I would have liked to see the zero code cleaned up too. I'm not sure how the contact is. I'm tempted to say do it anyway as it seems simple enough and if it happens to break zero someone will shout and we do a fix. Otherwise the chances that this cleanup will get applied to the zero code seem very low.
>>
>> David
>>
>>>
>>> On 26 okt 2012, at 13:58, Staffan Larsen<staffan.larsen at oracle.com
>>> <mailto:staffan.larsen at oracle.com>>  wrote:
>>>
>>>>
>>>> On 26 okt 2012, at 13:35, David Holmes<David.Holmes at oracle.com
>>>> <mailto:David.Holmes at oracle.com>>  wrote:
>>>>
>>>>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>>>> define is always set when compiling these files it is not necessary
>>>>>> to use it in the source files. The usage was originally added during
>>>>>> the porting to make it easier to see changes against the base linux
>>>>>> version.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>>>
>>>>> Generally looks okay (though now I see some of the actual BSD code it
>>>>> makes me a little nervous!). A couple of minor things:
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>> os_bsd.cpp:
>>>>>
>>>>> 977 }
>>>>> 978 #elif
>>>>>
>>>>> 3957 return true;
>>>>> 3958 #elif
>>>>> 3959 return false;
>>>>>
>>>>> Shouldn't the elif's have become an else?
>>>>>
>>>>> Ditto for os_bsd_x86.cpp:
>>>>>
>>>>> 850 #elif
>>>>
>>>> You are right. I've fixed this.
>>>>
>>>>> Also you can probably do the same thing for bsd_zero:
>>>>> /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.
>>>>
>>>> I didn't touch the zero files since I wasn't sure who maintains it.
>>>> I'm not sure how to build it so I didn't want to do changes.
>>>>
>>>> /Staffan
>>>>
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks,
>>>>>> /Staffan
>>>>
>>>
>

From daniel.daugherty at oracle.com  Mon Oct 29 04:54:10 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 29 Oct 2012 07:54:10 -0400
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508E673C.30902@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>	<508A7592.4070800@oracle.com>	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>	<508B23D8.2@oracle.com>	<A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
	<508E673C.30902@oracle.com>
Message-ID: <508E6E62.3080708@oracle.com>

On 10/29/12 7:23 AM, David Holmes wrote:
> On 29/10/2012 7:30 PM, Staffan Larsen wrote:
>> Here's a version with the zero changes as well: 
>> http://cr.openjdk.java.net/~sla/8001619/webrev.02/
>>
>> If it looks good, I'll push this version instead.
>
> Some of the conditionals are puzzling to me given this was all done 
> for the MacOSX port:
>
>  326 #ifdef __APPLE__
>  ...
>  331 #elif defined(__OpenBSD__)
>  ...
>  342 #elif defined(_ALLBSD_SOURCE)
>  ...
>
> I would have expected __APPLE__ to always be defined (else it is 
> redundant everywhere else!), but then that would preclude the 
> _ALLBSD_SOURCE code from being used.

The project that we (in Oracle) called the "MacOS X Port" project
imported changes from the BSD Port project:

     http://hg.openjdk.java.net/bsd-port/bsd-port

and from the MacOS X Port project:

     http://hg.openjdk.java.net/macosx-port/macosx-port

so there are multiple "flavors" of BSD in the mix...

Dan



>
> Maybe it is best to leave this after all - sorry :(
>
> David
>
>
>
>> /Staffan
>>
>> On 27 okt 2012, at 01:59, David Holmes<David.Holmes at oracle.com>  wrote:
>>
>>> On 26/10/2012 10:03 PM, Staffan Larsen wrote:
>>>> Oh... and new webrev at: 
>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.01/
>>>
>>> Thumbs up.
>>>
>>> But for completeness I would have liked to see the zero code cleaned 
>>> up too. I'm not sure how the contact is. I'm tempted to say do it 
>>> anyway as it seems simple enough and if it happens to break zero 
>>> someone will shout and we do a fix. Otherwise the chances that this 
>>> cleanup will get applied to the zero code seem very low.
>>>
>>> David
>>>
>>>>
>>>> On 26 okt 2012, at 13:58, Staffan Larsen<staffan.larsen at oracle.com
>>>> <mailto:staffan.larsen at oracle.com>>  wrote:
>>>>
>>>>>
>>>>> On 26 okt 2012, at 13:35, David Holmes<David.Holmes at oracle.com
>>>>> <mailto:David.Holmes at oracle.com>>  wrote:
>>>>>
>>>>>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>>>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>>>>> define is always set when compiling these files it is not necessary
>>>>>>> to use it in the source files. The usage was originally added 
>>>>>>> during
>>>>>>> the porting to make it easier to see changes against the base linux
>>>>>>> version.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>>>>
>>>>>> Generally looks okay (though now I see some of the actual BSD 
>>>>>> code it
>>>>>> makes me a little nervous!). A couple of minor things:
>>>>>
>>>>> Thanks.
>>>>>
>>>>>>
>>>>>> os_bsd.cpp:
>>>>>>
>>>>>> 977 }
>>>>>> 978 #elif
>>>>>>
>>>>>> 3957 return true;
>>>>>> 3958 #elif
>>>>>> 3959 return false;
>>>>>>
>>>>>> Shouldn't the elif's have become an else?
>>>>>>
>>>>>> Ditto for os_bsd_x86.cpp:
>>>>>>
>>>>>> 850 #elif
>>>>>
>>>>> You are right. I've fixed this.
>>>>>
>>>>>> Also you can probably do the same thing for bsd_zero:
>>>>>> /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero 
>>>>>> folk.
>>>>>
>>>>> I didn't touch the zero files since I wasn't sure who maintains it.
>>>>> I'm not sure how to build it so I didn't want to do changes.
>>>>>
>>>>> /Staffan
>>>>>
>>>>>
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks,
>>>>>>> /Staffan
>>>>>
>>>>
>>

From staffan.larsen at oracle.com  Mon Oct 29 05:40:44 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 29 Oct 2012 13:40:44 +0100
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508E673C.30902@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>
	<508B23D8.2@oracle.com>
	<A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
	<508E673C.30902@oracle.com>
Message-ID: <8A1DC05A-0DFF-4A10-AED1-AD2DEF1F5577@oracle.com>

I agree that the usage of __APPLE__ and _ALLBSD_SOURCE is confusing. I've assumed that _ALLBSD_SOURCE is always defined in the src/os/bsd folders, but that __APPLE__ is not always defined there (or at least that there exists forks where it makes sense for __APPLE__ not be defined).

/Staffan 

On 29 okt 2012, at 12:23, David Holmes <David.Holmes at oracle.com> wrote:

> On 29/10/2012 7:30 PM, Staffan Larsen wrote:
>> Here's a version with the zero changes as well: http://cr.openjdk.java.net/~sla/8001619/webrev.02/
>> 
>> If it looks good, I'll push this version instead.
> 
> Some of the conditionals are puzzling to me given this was all done for the MacOSX port:
> 
> 326 #ifdef __APPLE__
> ...
> 331 #elif defined(__OpenBSD__)
> ...
> 342 #elif defined(_ALLBSD_SOURCE)
> ...
> 
> I would have expected __APPLE__ to always be defined (else it is redundant everywhere else!), but then that would preclude the _ALLBSD_SOURCE code from being used.
> 
> Maybe it is best to leave this after all - sorry :(
> 
> David
> 
> 
> 
>> /Staffan
>> 
>> On 27 okt 2012, at 01:59, David Holmes<David.Holmes at oracle.com>  wrote:
>> 
>>> On 26/10/2012 10:03 PM, Staffan Larsen wrote:
>>>> Oh... and new webrev at: http://cr.openjdk.java.net/~sla/8001619/webrev.01/
>>> 
>>> Thumbs up.
>>> 
>>> But for completeness I would have liked to see the zero code cleaned up too. I'm not sure how the contact is. I'm tempted to say do it anyway as it seems simple enough and if it happens to break zero someone will shout and we do a fix. Otherwise the chances that this cleanup will get applied to the zero code seem very low.
>>> 
>>> David
>>> 
>>>> 
>>>> On 26 okt 2012, at 13:58, Staffan Larsen<staffan.larsen at oracle.com
>>>> <mailto:staffan.larsen at oracle.com>>  wrote:
>>>> 
>>>>> 
>>>>> On 26 okt 2012, at 13:35, David Holmes<David.Holmes at oracle.com
>>>>> <mailto:David.Holmes at oracle.com>>  wrote:
>>>>> 
>>>>>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>>>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>>>>> define is always set when compiling these files it is not necessary
>>>>>>> to use it in the source files. The usage was originally added during
>>>>>>> the porting to make it easier to see changes against the base linux
>>>>>>> version.
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>>>> 
>>>>>> Generally looks okay (though now I see some of the actual BSD code it
>>>>>> makes me a little nervous!). A couple of minor things:
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>>> 
>>>>>> os_bsd.cpp:
>>>>>> 
>>>>>> 977 }
>>>>>> 978 #elif
>>>>>> 
>>>>>> 3957 return true;
>>>>>> 3958 #elif
>>>>>> 3959 return false;
>>>>>> 
>>>>>> Shouldn't the elif's have become an else?
>>>>>> 
>>>>>> Ditto for os_bsd_x86.cpp:
>>>>>> 
>>>>>> 850 #elif
>>>>> 
>>>>> You are right. I've fixed this.
>>>>> 
>>>>>> Also you can probably do the same thing for bsd_zero:
>>>>>> /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.
>>>>> 
>>>>> I didn't touch the zero files since I wasn't sure who maintains it.
>>>>> I'm not sure how to build it so I didn't want to do changes.
>>>>> 
>>>>> /Staffan
>>>>> 
>>>>> 
>>>>>> 
>>>>>> David
>>>>>> -----
>>>>>> 
>>>>>>> Thanks,
>>>>>>> /Staffan
>>>>> 
>>>> 
>> 


From coleen.phillimore at oracle.com  Mon Oct 29 06:05:41 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 29 Oct 2012 09:05:41 -0400
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>
	<508B23D8.2@oracle.com>
	<A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
Message-ID: <508E7F25.6080309@oracle.com>


Staffan,
I think this looks fine to me.  It appears that Roman Kennke 
rkennke at redhat.com is working on Zero, and has sent a set of changes to 
us to integrate.   Christian Thalinger is doing this. He hasn't changed 
bsd_zero with his change so there won't be any conflict.  He'll likely 
let you know if you (doubtfully) broke this.

Coleen

On 10/29/2012 5:30 AM, Staffan Larsen wrote:
> Here's a version with the zero changes as well: http://cr.openjdk.java.net/~sla/8001619/webrev.02/
>
> If it looks good, I'll push this version instead.
>
> /Staffan
>
> On 27 okt 2012, at 01:59, David Holmes <David.Holmes at oracle.com> wrote:
>
>> On 26/10/2012 10:03 PM, Staffan Larsen wrote:
>>> Oh... and new webrev at: http://cr.openjdk.java.net/~sla/8001619/webrev.01/
>> Thumbs up.
>>
>> But for completeness I would have liked to see the zero code cleaned up too. I'm not sure how the contact is. I'm tempted to say do it anyway as it seems simple enough and if it happens to break zero someone will shout and we do a fix. Otherwise the chances that this cleanup will get applied to the zero code seem very low.
>>
>> David
>>
>>> On 26 okt 2012, at 13:58, Staffan Larsen <staffan.larsen at oracle.com
>>> <mailto:staffan.larsen at oracle.com>> wrote:
>>>
>>>> On 26 okt 2012, at 13:35, David Holmes <David.Holmes at oracle.com
>>>> <mailto:David.Holmes at oracle.com>> wrote:
>>>>
>>>>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>>>> define is always set when compiling these files it is not necessary
>>>>>> to use it in the source files. The usage was originally added during
>>>>>> the porting to make it easier to see changes against the base linux
>>>>>> version.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>>> Generally looks okay (though now I see some of the actual BSD code it
>>>>> makes me a little nervous!). A couple of minor things:
>>>> Thanks.
>>>>
>>>>> os_bsd.cpp:
>>>>>
>>>>> 977 }
>>>>> 978 #elif
>>>>>
>>>>> 3957 return true;
>>>>> 3958 #elif
>>>>> 3959 return false;
>>>>>
>>>>> Shouldn't the elif's have become an else?
>>>>>
>>>>> Ditto for os_bsd_x86.cpp:
>>>>>
>>>>> 850 #elif
>>>> You are right. I've fixed this.
>>>>
>>>>> Also you can probably do the same thing for bsd_zero:
>>>>> /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.
>>>> I didn't touch the zero files since I wasn't sure who maintains it.
>>>> I'm not sure how to build it so I didn't want to do changes.
>>>>
>>>> /Staffan
>>>>
>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks,
>>>>>> /Staffan


From erik.x.helin at oracle.com  Mon Oct 29 07:29:22 2012
From: erik.x.helin at oracle.com (Erik Helin)
Date: Mon, 29 Oct 2012 15:29:22 +0100
Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA
	system
Message-ID: <508E92C2.2080604@oracle.com>

Hi everyone,

the webrev can be found at:

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

Summary:
The bug existed because the function 'Arguments::parse' changed the 
value of the flags 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' 
depending on the value of the flag 'UseNUMA'.

The problem was that the function 'os::init_2' checks if NUMA is 
supported on the system, and if it is not supported, sets 'UseNUMA' to 
'false'.

Since 'Arguments::parse' is called before 'os::init_2' in the function 
'Threads::create_vm', the result was that 'UseNUMA' was set to false and 
'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly
modified.

The fix splits the function 'Arguments::parse' into three functions:
- 'Arguments::parse' now only parses the arguments.
- 'Arguments::adjust_before_os' adjusts the flags that must be adjusted
   *before* 'os::init_after_parsing_flags'.
- 'Arguments::adjust_after_os' adjusts the flags that must be adjusted
   *after* 'os::init_after_parsing_flags'.

Note that three functions are necessary since the flag 'UseLargePages'
has to be adjusted *before* 'os::init_2' is called.

This change also renames 'os::init' to 'os::init_before_parsing_flags'
and 'os::init_2' to 'os::init_after_parsing_args'. This was done to try 
to make the relationship between the functions in 'Arguments' and the 
functions in 'os' as clear as possible.

Testing:
JPRT

Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal -version' on a 
system that does not support NUMA shows that 'UseNUMAInterleaving' and 
'MinHeapDeltaBytes' now have correct values.

Thanks,
Erik

From jiangli.zhou at oracle.com  Mon Oct 29 09:37:08 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Mon, 29 Oct 2012 09:37:08 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <508D3A37.7060600@oracle.com>
References: <5089C7E1.2040206@oracle.com> <508A4CD4.2090009@oracle.com>
	<508AC578.2000603@oracle.com> <508B2222.4070603@oracle.com>
	<508D3A37.7060600@oracle.com>
Message-ID: <508EB0B4.3050905@oracle.com>

Hi Alan,

Thanks a lot for those information. I'm discussing with Christian in a 
separate thread regarding this issue.

Thanks,
Jiangli

On 10/28/2012 06:59 AM, Alan Bateman wrote:
> On 27/10/2012 00:52, Jiangli Zhou wrote:
>> Hi Alan,
>>
>> I tried a few experiments with the makefiles. Looks like 
>> jdk/make/java/invoke/Makefile is not the right place to set the 
>> -timeoutFactor option. I'm reluctant to set a large timeoutFactor in 
>> jdk/test/Makefile. Some of the java.lang.invoke jtreg test take long 
>> time to run. For example, the test.java.lang.invoke.MethodHandlesTest 
>> takes about 1.5 hour to run on certain devices. Since there are only 
>> 3~4 java.lang.invoke tests have the timeout issue and each of them 
>> has very different execution duration, I'm inclined to set each 
>> specific timeout value for different test. Please let me know your 
>> opinion.
>>
>> Thanks,
>> Jiangli
>>
> If you are running the tests via the make file then this should work:
>
> make EXTRA_JTREG_OPTIONS=-timeoutFactor:10 jdk_lang
>
> but I see that the Makefile puts its own defaults, 
> including-timeoutFactor:4, after the options set via 
> EXTRA_JTREG_OPTIONS. That plus jtreg doesn't allow the -timeoutFactor 
> to be specified more than once on the command line. Minimally we 
> should fix the make file so that options specified via 
> EXTRA_JTREG_OPTIONS override any defaults in the make file.
>
> I think you'll need to check with Christian or John as to whether they 
> would object to have very high timeouts on these tests. Personally I 
> think it should be possible to specify a timeout scaling factor when 
> running the tests rather than having each test specify a /timeout for 
> the slowest possible machine that the test might run on.
>
> -Alan.
>
>
>
>


From vladimir.kozlov at oracle.com  Mon Oct 29 10:29:24 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 29 Oct 2012 10:29:24 -0700
Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of
	dead nodes
In-Reply-To: <508DF417.7090906@oracle.com>
References: <508DF417.7090906@oracle.com>
Message-ID: <04038883-A951-4916-BA99-F52D71B4B928@oracle.com>

Bharadwaj,

These changes look much better. Sorry, I suggested to add verify_live_node_count() method before but your current code don't need it, just use count_live_nodes_by_graph_walk(). An other note: without LogCompilation verification code should produce some info on tty.

Thanks,
Vladimir

On Oct 28, 2012, at 8:12 PM, Bharadwaj Yadavalli wrote:

> I'd like to get a code review of the changes at http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_01/
> 
> These changes are made to keep an (almost) accurate running count of the reachable (live) flow graph nodes. This will result in a more realistic node count for various phases of C2 to decide on whether to proceed with optimizations or not. Prior to these changes, C2 bails out of compilation based on the number of nodes created which typically larger than the number of reachable (live) nodes.
> 
> I observed no significant degradation in C2 compilation time of all classes in rt.jar time due to these changes.
> 
> Thanks,
> 
> Bharadwaj
> 


From vladimir.kozlov at oracle.com  Mon Oct 29 10:55:31 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 29 Oct 2012 10:55:31 -0700
Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in
	source code
In-Reply-To: <16596034-0B88-4742-A7FE-3B8B546DE759@oracle.com>
References: <508EB0F2.80408@oracle.com>
	<21484E86-B262-4581-8AEC-93DD737D8A28@oracle.com>
	<4F2212B0-ED56-43A9-A8BC-D0521769769E@oracle.com>
	<16596034-0B88-4742-A7FE-3B8B546DE759@oracle.com>
Message-ID: <4B619AF9-2BB7-4878-AB2D-4B63E942831D@oracle.com>


On Oct 29, 2012, at 10:48 AM, Christian Thalinger wrote:

> Sure:  http://cr.openjdk.java.net/~twisti/6518907
> 
> Btw. the bug synopsis (which is called Summary in JIRA) is actually:
> 
> 6518907: too many platform-specific ifdefs in source code
> 
> -- Chris
> 
> On Oct 29, 2012, at 10:35 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> Christian,
>> 
>> Can you move web rev  to cr.openjdk so people outside can review it. We then can ask RH and SAP if they use that code.
>> 
>> Thanks,
>> Vladimir
>> 
>> On Oct 29, 2012, at 10:31 AM, Christian Thalinger wrote:
>> 
>>> 
>>> On Oct 29, 2012, at 9:38 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
>>> 
>>>> Took a pass at purging the platform-specific IA64 refs throughout the source base.
>>> 
>>> In general I think this is okay.  The only thing I'm worried is that maybe some defines or such may be used when compiling Zero on IA64.  Although I don't know if anyone is doing that.
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>>         --mm
>>>> 
>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907
>>>> WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-6518907/
>>> 
>> 
> 


From christian.thalinger at oracle.com  Mon Oct 29 11:52:36 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Oct 2012 11:52:36 -0700
Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in
	source code
In-Reply-To: <4B619AF9-2BB7-4878-AB2D-4B63E942831D@oracle.com>
References: <508EB0F2.80408@oracle.com>
	<21484E86-B262-4581-8AEC-93DD737D8A28@oracle.com>
	<4F2212B0-ED56-43A9-A8BC-D0521769769E@oracle.com>
	<16596034-0B88-4742-A7FE-3B8B546DE759@oracle.com>
	<4B619AF9-2BB7-4878-AB2D-4B63E942831D@oracle.com>
Message-ID: <6E8A6F30-47EF-40F3-A26C-24A83B3A6369@oracle.com>


On Oct 29, 2012, at 10:55 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> 
> On Oct 29, 2012, at 10:48 AM, Christian Thalinger wrote:
> 
>> Sure:  http://cr.openjdk.java.net/~twisti/6518907
>> 
>> Btw. the bug synopsis (which is called Summary in JIRA) is actually:
>> 
>> 6518907: too many platform-specific ifdefs in source code
>> 
>> -- Chris
>> 
>> On Oct 29, 2012, at 10:35 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Christian,
>>> 
>>> Can you move web rev  to cr.openjdk so people outside can review it. We then can ask RH and SAP if they use that code.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On Oct 29, 2012, at 10:31 AM, Christian Thalinger wrote:
>>> 
>>>> 
>>>> On Oct 29, 2012, at 9:38 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
>>>> 
>>>>> Took a pass at purging the platform-specific IA64 refs throughout the source base.
>>>> 
>>>> In general I think this is okay.  The only thing I'm worried is that maybe some defines or such may be used when compiling Zero on IA64.  Although I don't know if anyone is doing that.

Apparently Debian is doing it:

http://packages.debian.org/sid/ia64/openjdk-7-jre-headless

-- Chris

>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>>        --mm
>>>>> 
>>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907
>>>>> WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-6518907/
>>>> 
>>> 
>> 
> 


From sagar.md at gmail.com  Mon Oct 29 11:58:36 2012
From: sagar.md at gmail.com (Sagar M D)
Date: Tue, 30 Oct 2012 00:28:36 +0530
Subject: unwinding java frame
Message-ID: <CAMkjO=_1hd7VpOfWqb2Ju93L952s05E_SFJydXxgNUnX3SdbUw@mail.gmail.com>

Hi All,

How to get the back trace of complete stack which includes java compiled
and interpreter frame using GDB on Linux . How to make GDB to understand
java compiled and interpreter frame?

Thanks,
Sagar

From vladimir.kozlov at oracle.com  Mon Oct 29 12:00:29 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 29 Oct 2012 12:00:29 -0700
Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source
	code
In-Reply-To: <6E8A6F30-47EF-40F3-A26C-24A83B3A6369@oracle.com>
References: <508EB0F2.80408@oracle.com>
	<21484E86-B262-4581-8AEC-93DD737D8A28@oracle.com>
	<4F2212B0-ED56-43A9-A8BC-D0521769769E@oracle.com>
	<16596034-0B88-4742-A7FE-3B8B546DE759@oracle.com>
	<4B619AF9-2BB7-4878-AB2D-4B63E942831D@oracle.com>
	<6E8A6F30-47EF-40F3-A26C-24A83B3A6369@oracle.com>
Message-ID: <508ED24D.9060006@oracle.com>

 > Apparently Debian is doing it:
 >
 > http://packages.debian.org/sid/ia64/openjdk-7-jre-headless
 >
 > -- Chris

Can we find which code and in which file they need?

Vladimir

Christian Thalinger wrote:
> On Oct 29, 2012, at 10:55 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> On Oct 29, 2012, at 10:48 AM, Christian Thalinger wrote:
>>
>>> Sure:  http://cr.openjdk.java.net/~twisti/6518907
>>>
>>> Btw. the bug synopsis (which is called Summary in JIRA) is actually:
>>>
>>> 6518907: too many platform-specific ifdefs in source code
>>>
>>> -- Chris
>>>
>>> On Oct 29, 2012, at 10:35 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>
>>>> Christian,
>>>>
>>>> Can you move web rev  to cr.openjdk so people outside can review it. We then can ask RH and SAP if they use that code.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On Oct 29, 2012, at 10:31 AM, Christian Thalinger wrote:
>>>>
>>>>> On Oct 29, 2012, at 9:38 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
>>>>>
>>>>>> Took a pass at purging the platform-specific IA64 refs throughout the source base.
>>>>> In general I think this is okay.  The only thing I'm worried is that maybe some defines or such may be used when compiling Zero on IA64.  Although I don't know if anyone is doing that.
> 
> 
>>>>> -- Chris
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>        --mm
>>>>>>
>>>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907
>>>>>> WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-6518907/
> 

From krystal.mo at oracle.com  Mon Oct 29 12:39:57 2012
From: krystal.mo at oracle.com (Krystal Mo)
Date: Tue, 30 Oct 2012 03:39:57 +0800
Subject: unwinding java frame
In-Reply-To: <CAMkjO=_1hd7VpOfWqb2Ju93L952s05E_SFJydXxgNUnX3SdbUw@mail.gmail.com>
References: <CAMkjO=_1hd7VpOfWqb2Ju93L952s05E_SFJydXxgNUnX3SdbUw@mail.gmail.com>
Message-ID: <508EDB8D.6090808@oracle.com>

Hi Sagar,

If you're running on a debug build (fastdebug/jvmg) of HotSpot, from gdb you
could invoke helper functions defined in src/share/vm/utilities/debug.cpp to
gain easier access to HotSpot's internal data structures.

Specifically,
   to print the stack trace of the current thread, use ps();
   to print the stack trace of all thread, use pss();

I've attached an example at the end of this email.

There are of course other ways of doing it in gdb, that may or may not 
require
a debug build.

Instead of gdb, I use SA-based (Serviceability Agent) tools more often,
e.g. jstack -m. It works on live Java processes and core dumps, and doesn't
require a debug build of HotSpot.

Hope it helps,
- Kris

Example:

Start a Groovy shell, and then attach gdb onto it:

kmo at ubuntu:~
$ jps
24548 Jps
24514 GroovyStarter
kmo at ubuntu:~
$ sudo gdb
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb) attach 24514
Attaching to process 24514
Reading symbols from /home/kmo/testjdk/hotspot-comp/bin/java...(no 
debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no 
debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7f29180c9700 (LWP 24541)]
[New Thread 0x7f29136fd700 (LWP 24538)]
[New Thread 0x7f29137fe700 (LWP 24537)]
[New Thread 0x7f291827f700 (LWP 24536)]
[New Thread 0x7f2920130700 (LWP 24535)]
[New Thread 0x7f2920231700 (LWP 24534)]
[New Thread 0x7f2920332700 (LWP 24533)]
[New Thread 0x7f2920433700 (LWP 24532)]
[New Thread 0x7f2920534700 (LWP 24531)]
[New Thread 0x7f2920d18700 (LWP 24530)]
[New Thread 0x7f292c14a700 (LWP 24529)]
[New Thread 0x7f2920e19700 (LWP 24528)]
[New Thread 0x7f292dd33700 (LWP 24527)]
[New Thread 0x7f292de34700 (LWP 24526)]
[New Thread 0x7f292df35700 (LWP 24525)]
[New Thread 0x7f292e036700 (LWP 24524)]
[New Thread 0x7f2932272700 (LWP 24523)]
Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0
Reading symbols from 
/home/kmo/testjdk/hotspot-comp/bin/../jre/lib/amd64/jli/libjli.so...(no 
debugging symbols found)...done.
Loaded symbols for 
/home/kmo/testjdk/hotspot-comp/bin/../jre/lib/amd64/jli/libjli.so
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging 
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging 
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from 
/home/kmo/testjdk/hotspot-comp/jre/lib/amd64/server/libjvm.so...Reading 
symbols from 
/home/kmo/testjdk/hotspot-comp/jre/lib/amd64/server/libjvm.debuginfo...done.
done.
Loaded symbols for 
/home/kmo/testjdk/hotspot-comp/jre/lib/amd64/server/libjvm.so
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...(no debugging 
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libm.so.6
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...(no debugging 
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/librt.so.1
Reading symbols from 
/home/kmo/testjdk/hotspot-comp/jre/lib/amd64/libverify.so...(no 
debugging symbols found)...done.
Loaded symbols for /home/kmo/testjdk/hotspot-comp/jre/lib/amd64/libverify.so
Reading symbols from 
/home/kmo/testjdk/hotspot-comp/jre/lib/amd64/libjava.so...(no debugging 
symbols found)...done.
Loaded symbols for /home/kmo/testjdk/hotspot-comp/jre/lib/amd64/libjava.so
Reading symbols from /lib/x86_64-linux-gnu/libnss_compat.so.2...(no 
debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_compat.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging 
symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1
Reading symbols from /lib/x86_64-linux-gnu/libnss_nis.so.2...(no 
debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_nis.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...(no 
debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
Reading symbols from 
/home/kmo/testjdk/hotspot-comp/jre/lib/amd64/libzip.so...(no debugging 
symbols found)...done.
Loaded symbols for /home/kmo/testjdk/hotspot-comp/jre/lib/amd64/libzip.so
Reading symbols from /tmp/libjansi-64-1.6.so...done.
Loaded symbols for /tmp/libjansi-64-1.6.so
0x00007f2931e57148 in pthread_join () from 
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) info threads
   Id   Target Id         Frame
   18   Thread 0x7f2932272700 (LWP 24523) "java" 0x00007f2931e5cd2d in 
read () from /lib/x86_64-linux-gnu/libpthread.so.0
   17   Thread 0x7f292e036700 (LWP 24524) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   16   Thread 0x7f292df35700 (LWP 24525) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   15   Thread 0x7f292de34700 (LWP 24526) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   14   Thread 0x7f292dd33700 (LWP 24527) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   13   Thread 0x7f2920e19700 (LWP 24528) "java" 0x00007f2931e5a0fe in 
pthread_cond_timedwait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   12   Thread 0x7f292c14a700 (LWP 24529) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   11   Thread 0x7f2920d18700 (LWP 24530) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   10   Thread 0x7f2920534700 (LWP 24531) "java" 0x00007f2931e5bfd0 in 
sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
   9    Thread 0x7f2920433700 (LWP 24532) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   8    Thread 0x7f2920332700 (LWP 24533) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   7    Thread 0x7f2920231700 (LWP 24534) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   6    Thread 0x7f2920130700 (LWP 24535) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   5    Thread 0x7f291827f700 (LWP 24536) "java" 0x00007f2931e5a0fe in 
pthread_cond_timedwait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   4    Thread 0x7f29137fe700 (LWP 24537) "java" 0x00007f2931e5a0fe in 
pthread_cond_timedwait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   3    Thread 0x7f29136fd700 (LWP 24538) "java" 0x00007f2931e59d84 in 
pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
   2    Thread 0x7f29180c9700 (LWP 24541) "java" 0x00007f2931e5a0fe in 
pthread_cond_timedwait@@GLIBC_2.3.2 ()
    from /lib/x86_64-linux-gnu/libpthread.so.0
* 1    Thread 0x7f2932274700 (LWP 24514) "java" 0x00007f2931e57148 in 
pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) t 18
[Switching to thread 18 (Thread 0x7f2932272700 (LWP 24523))]
#0  0x00007f2931e5cd2d in read () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) print ps()
$1 = void
(gdb) quit
A debugging session is active.

     Inferior 1 [process 24514] will be detached.

Quit anyway? (y or n) y
Detaching from program: /home/kmo/testjdk/hotspot-comp/bin/java, process 
24514
kmo at ubuntu:~
$

(Note: the ps() function, and a couple others, expects the "current 
thread" to be a Java thread.
Be sure to switch the thread to a Java thread before invoking them in 
gdb, otherwise you'll crash the debuggee process.
In this example, I switched to thread 18 first, which is the "main" Java 
thread.)

You may be wondering where the result of ps() went, well, here it is:

kmo at ubuntu:~
$ groovysh
Groovy Shell (2.0.1, JVM: 1.8.0-ea)
Type 'help' or '\h' for help.
------------------------------------------------------------------------------------------------------------------------------------------
groovy:000>
"Executing ps"
  for thread: "main" #1 prio=5 os_prio=0 tid=0x00007f292800c000 
nid=0x5fcb runnable [0x00007f293226c000]
    java.lang.Thread.State: RUNNABLE
    JavaThread state: _thread_in_native
Thread: 0x00007f292800c000  [0x5fcb] State: _running _has_called_back 0 
_at_poll_safepoint 0
    JavaThread state: _thread_in_native

  1 - frame( sp=0x00007f293226ccc0, unextended_sp=0x00007f293226ccc0, 
fp=0x00007f293226cd20, pc=0x00007f2922023c0c)
java.io.FileInputStream.readBytes(Native Method)
  2 - frame( sp=0x00007f293226cd30, unextended_sp=0x00007f293226cd40, 
fp=0x00007f293226cda0, pc=0x00007f29220063f4)
java.io.FileInputStream.read(FileInputStream.java:231)
  3 - frame( sp=0x00007f293226cdb0, unextended_sp=0x00007f293226cdb0, 
fp=0x00007f293226ce10, pc=0x00007f29220063f4)
java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
  4 - frame( sp=0x00007f293226ce20, unextended_sp=0x00007f293226ce40, 
fp=0x00000007db2c2030, pc=0x00007f29222d3c38)
java.io.BufferedInputStream.read(BufferedInputStream.java:254)
  5 - frame( sp=0x00007f293226ce70, unextended_sp=0x00007f293226ce70, 
fp=0x00007f293226cec0, pc=0x00007f29220063f4)
jline.Terminal.readCharacter(Terminal.java:99)
  6 - frame( sp=0x00007f293226ced0, unextended_sp=0x00007f293226ced0, 
fp=0x00007f293226cf20, pc=0x00007f29220063f4)
jline.UnixTerminal.readVirtualKey(UnixTerminal.java:122)
  7 - frame( sp=0x00007f293226cf30, unextended_sp=0x00007f293226cf38, 
fp=0x00007f293226cf88, pc=0x00007f29220063f4)
jline.ConsoleReader.readVirtualKey(ConsoleReader.java:1606)
  8 - frame( sp=0x00007f293226cf98, unextended_sp=0x00007f293226cfa0, 
fp=0x00007f293226cfe8, pc=0x00007f29220063f4)
jline.ConsoleReader.readBinding(ConsoleReader.java:764)
  9 - frame( sp=0x00007f293226cff8, unextended_sp=0x00007f293226d008, 
fp=0x00007f293226d050, pc=0x00007f2922006453)
jline.ConsoleReader.readLine(ConsoleReader.java:511)
10 - frame( sp=0x00007f293226d060, unextended_sp=0x00007f293226d0a8, 
fp=0x00007f293226d100, pc=0x00007f2922006453)
jline.ConsoleReader.readLine(ConsoleReader.java:457)
11 - frame( sp=0x00007f293226d110, unextended_sp=0x00007f293226d110, 
fp=0x00007f293226d160, pc=0x00007f2922006453)
jline.ConsoleReader$readLine.call
12 - frame( sp=0x00007f293226d170, unextended_sp=0x00007f293226d170, 
fp=0x00007f293226d1c8, pc=0x00007f2922006b01)
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
13 - frame( sp=0x00007f293226d1d8, unextended_sp=0x00007f293226d1d8, 
fp=0x00007f293226d230, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
14 - frame( sp=0x00007f293226d240, unextended_sp=0x00007f293226d240, 
fp=0x00007f293226d298, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
15 - frame( sp=0x00007f293226d2a8, unextended_sp=0x00007f293226d2a8, 
fp=0x00007f293226d300, pc=0x00007f2922006b01)
org.codehaus.groovy.tools.shell.InteractiveShellRunner.readLine(InteractiveShellRunner.groovy:89)
16 - frame( sp=0x00007f293226d310, unextended_sp=0x00007f293226d338, 
fp=0x00007f293226d380, pc=0x00007f2922006453)
org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:75)
17 - frame( sp=0x00007f293226d390, unextended_sp=0x00007f293226d3c0, 
fp=0x00007f293226d408, pc=0x00007f2922006570)
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work
C frame (sp=0x00007f293226d418 unextended sp=0x00007f293226d418, 
fp=0x00007f293226d480, pc=0x00007f2922000681)
(~Stub::call_stub)
      BufferBlob (0x00007f29220003d0) used for StubRoutines (1)

18 - frame( sp=0x00007f293226dcb0, unextended_sp=0x00007f293226dcb0, 
fp=0x00007f293226dd08, pc=0x00007f2922023c0c)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19 - frame( sp=0x00007f293226dd18, unextended_sp=0x00007f293226dd28, 
fp=0x00007f293226dd80, pc=0x00007f2922006453)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
20 - frame( sp=0x00007f293226dd90, unextended_sp=0x00007f293226dd98, 
fp=0x00007f293226ddf0, pc=0x00007f2922006453)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
21 - frame( sp=0x00007f293226de00, unextended_sp=0x00007f293226de00, 
fp=0x00007f293226de58, pc=0x00007f2922006b01)
java.lang.reflect.Method.invoke(Method.java:474)
22 - frame( sp=0x00007f293226de68, unextended_sp=0x00007f293226de70, 
fp=0x00007f293226dec8, pc=0x00007f2922006453)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
23 - frame( sp=0x00007f293226ded8, unextended_sp=0x00007f293226dee8, 
fp=0x00007f293226df40, pc=0x00007f2922006453)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
24 - frame( sp=0x00007f293226df50, unextended_sp=0x00007f293226df58, 
fp=0x00007f293226dfb0, pc=0x00007f2922006453)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1074)
25 - frame( sp=0x00007f293226dfc0, unextended_sp=0x00007f293226e020, 
fp=0x00007f293226e098, pc=0x00007f2922006b01)
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:128)
26 - frame( sp=0x00007f293226e0a8, unextended_sp=0x00007f293226e0c0, 
fp=0x00007f293226e120, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:148)
27 - frame( sp=0x00007f293226e130, unextended_sp=0x00007f293226e130, 
fp=0x00007f293226e188, pc=0x00007f2922006453)
org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:100)
C frame (sp=0x00007f293226e198 unextended sp=0x00007f293226e1a8, 
fp=0x00007f293226e210, pc=0x00007f2922000681)
(~Stub::call_stub)
      BufferBlob (0x00007f29220003d0) used for StubRoutines (1)

28 - frame( sp=0x00007f293226ea40, unextended_sp=0x00007f293226ea40, 
fp=0x00007f293226ea98, pc=0x00007f2922023c0c)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
29 - frame( sp=0x00007f293226eaa8, unextended_sp=0x00007f293226eab8, 
fp=0x00007f293226eb10, pc=0x00007f2922006453)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
30 - frame( sp=0x00007f293226eb20, unextended_sp=0x00007f293226eb28, 
fp=0x00007f293226eb80, pc=0x00007f2922006453)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
31 - frame( sp=0x00007f293226eb90, unextended_sp=0x00007f293226eb90, 
fp=0x00007f293226ebe8, pc=0x00007f2922006b01)
java.lang.reflect.Method.invoke(Method.java:474)
32 - frame( sp=0x00007f293226ebf8, unextended_sp=0x00007f293226ec00, 
fp=0x00007f293226ec58, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:272)
33 - frame( sp=0x00007f293226ec68, unextended_sp=0x00007f293226ec78, 
fp=0x00007f293226ecd0, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:52)
34 - frame( sp=0x00007f293226ece0, unextended_sp=0x00007f293226ece8, 
fp=0x00007f293226ed40, pc=0x00007f2922006b01)
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
35 - frame( sp=0x00007f293226ed50, unextended_sp=0x00007f293226ed50, 
fp=0x00007f293226eda8, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
36 - frame( sp=0x00007f293226edb8, unextended_sp=0x00007f293226edb8, 
fp=0x00007f293226ee10, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:137)
37 - frame( sp=0x00007f293226ee20, unextended_sp=0x00007f293226ee20, 
fp=0x00007f293226ee70, pc=0x00007f2922006b01)
org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:57)
38 - frame( sp=0x00007f293226ee80, unextended_sp=0x00007f293226eeb0, 
fp=0x00007f293226eef8, pc=0x00007f2922006278)
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$run
C frame (sp=0x00007f293226ef08 unextended sp=0x00007f293226ef08, 
fp=0x00007f293226ef70, pc=0x00007f2922000681)
(~Stub::call_stub)
      BufferBlob (0x00007f29220003d0) used for StubRoutines (1)

39 - frame( sp=0x00007f293226f7a0, unextended_sp=0x00007f293226f7a0, 
fp=0x00007f293226f7f8, pc=0x00007f2922023c0c)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
40 - frame( sp=0x00007f293226f808, unextended_sp=0x00007f293226f818, 
fp=0x00007f293226f870, pc=0x00007f2922006453)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
41 - frame( sp=0x00007f293226f880, unextended_sp=0x00007f293226f888, 
fp=0x00007f293226f8e0, pc=0x00007f2922006453)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
42 - frame( sp=0x00007f293226f8f0, unextended_sp=0x00007f293226f8f0, 
fp=0x00007f293226f948, pc=0x00007f2922006b01)
java.lang.reflect.Method.invoke(Method.java:474)
43 - frame( sp=0x00007f293226f958, unextended_sp=0x00007f293226f960, 
fp=0x00007f293226f9b8, pc=0x00007f2922006453)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
44 - frame( sp=0x00007f293226f9c8, unextended_sp=0x00007f293226f9d8, 
fp=0x00007f293226fa30, pc=0x00007f2922006453)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
45 - frame( sp=0x00007f293226fa40, unextended_sp=0x00007f293226fa48, 
fp=0x00007f293226faa0, pc=0x00007f2922006453)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1074)
46 - frame( sp=0x00007f293226fab0, unextended_sp=0x00007f293226fb10, 
fp=0x00007f293226fb88, pc=0x00007f2922006b01)
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:128)
47 - frame( sp=0x00007f293226fb98, unextended_sp=0x00007f293226fbb0, 
fp=0x00007f293226fc10, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:148)
48 - frame( sp=0x00007f293226fc20, unextended_sp=0x00007f293226fc20, 
fp=0x00007f293226fc78, pc=0x00007f2922006453)
org.codehaus.groovy.tools.shell.InteractiveShellRunner.run(InteractiveShellRunner.groovy:66)
49 - frame( sp=0x00007f293226fc88, unextended_sp=0x00007f293226fca0, 
fp=0x00007f293226fce8, pc=0x00007f2922006926)
java_lang_Runnable$run.call
50 - frame( sp=0x00007f293226fcf8, unextended_sp=0x00007f293226fcf8, 
fp=0x00007f293226fd50, pc=0x00007f2922006b01)
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
51 - frame( sp=0x00007f293226fd60, unextended_sp=0x00007f293226fd60, 
fp=0x00007f293226fdb8, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
52 - frame( sp=0x00007f293226fdc8, unextended_sp=0x00007f293226fdc8, 
fp=0x00007f293226fe20, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
53 - frame( sp=0x00007f293226fe30, unextended_sp=0x00007f293226fe30, 
fp=0x00007f293226fe80, pc=0x00007f2922006b01)
org.codehaus.groovy.tools.shell.Groovysh.run(Groovysh.groovy:463)
54 - frame( sp=0x00007f293226fe90, unextended_sp=0x00007f293226ff50, 
fp=0x00007f293226ffa0, pc=0x00007f29220063f4)
org.codehaus.groovy.tools.shell.Groovysh.run(Groovysh.groovy:402)
C frame (sp=0x00007f293226ffb0 unextended sp=0x00007f293226ffd0, 
fp=0x00007f2932270040, pc=0x00007f2922000681)
(~Stub::call_stub)
      BufferBlob (0x00007f29220003d0) used for StubRoutines (1)

55 - frame( sp=0x00007f2932270870, unextended_sp=0x00007f2932270870, 
fp=0x00007f29322708c8, pc=0x00007f2922023c0c)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
56 - frame( sp=0x00007f29322708d8, unextended_sp=0x00007f29322708e8, 
fp=0x00007f2932270940, pc=0x00007f2922006453)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
57 - frame( sp=0x00007f2932270950, unextended_sp=0x00007f2932270958, 
fp=0x00007f29322709b0, pc=0x00007f2922006453)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
58 - frame( sp=0x00007f29322709c0, unextended_sp=0x00007f29322709c0, 
fp=0x00007f2932270a18, pc=0x00007f2922006b01)
java.lang.reflect.Method.invoke(Method.java:474)
59 - frame( sp=0x00007f2932270a28, unextended_sp=0x00007f2932270a30, 
fp=0x00007f2932270a88, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:231)
60 - frame( sp=0x00007f2932270a98, unextended_sp=0x00007f2932270aa8, 
fp=0x00007f2932270b00, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:64)
61 - frame( sp=0x00007f2932270b10, unextended_sp=0x00007f2932270b18, 
fp=0x00007f2932270b70, pc=0x00007f2922006b01)
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
62 - frame( sp=0x00007f2932270b80, unextended_sp=0x00007f2932270b80, 
fp=0x00007f2932270bd8, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
63 - frame( sp=0x00007f2932270be8, unextended_sp=0x00007f2932270be8, 
fp=0x00007f2932270c40, pc=0x00007f2922006453)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
64 - frame( sp=0x00007f2932270c50, unextended_sp=0x00007f2932270c50, 
fp=0x00007f2932270ca8, pc=0x00007f2922006b01)
org.codehaus.groovy.tools.shell.Main.main(Main.groovy:131)
C frame (sp=0x00007f2932270cb8 unextended sp=0x00007f2932270d38, 
fp=0x00007f2932270da0, pc=0x00007f2922000681)
(~Stub::call_stub)
      BufferBlob (0x00007f29220003d0) used for StubRoutines (1)

65 - frame( sp=0x00007f29322715d0, unextended_sp=0x00007f29322715d0, 
fp=0x00007f2932271630, pc=0x00007f2922023c0c)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
66 - frame( sp=0x00007f2932271640, unextended_sp=0x00007f2932271650, 
fp=0x00007f29322716a8, pc=0x00007f2922006453)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
67 - frame( sp=0x00007f29322716b8, unextended_sp=0x00007f29322716c0, 
fp=0x00007f2932271718, pc=0x00007f2922006453)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
68 - frame( sp=0x00007f2932271728, unextended_sp=0x00007f2932271728, 
fp=0x00007f2932271780, pc=0x00007f2922006b01)
java.lang.reflect.Method.invoke(Method.java:474)
69 - frame( sp=0x00007f2932271790, unextended_sp=0x00007f2932271798, 
fp=0x00007f29322717f0, pc=0x00007f2922006453)
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:106)
70 - frame( sp=0x00007f2932271800, unextended_sp=0x00007f2932271858, 
fp=0x00007f29322718a0, pc=0x00007f2922006278)
org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)

What happened was: the ps() function prints its output on tty, in this 
case that's the stdout of the debuggee process. So instead of seeing the 
output directly in gdb, we're seeing it on the Groovy shell side.

On 10/30/2012 02:58 AM, Sagar M D wrote:
> Hi All,
>
> How to get the back trace of complete stack which includes java compiled
> and interpreter frame using GDB on Linux . How to make GDB to understand
> java compiled and interpreter frame?
>
> Thanks,
> Sagar


From david.holmes at oracle.com  Mon Oct 29 20:29:01 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Oct 2012 13:29:01 +1000
Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA
	system
In-Reply-To: <508E92C2.2080604@oracle.com>
References: <508E92C2.2080604@oracle.com>
Message-ID: <508F497D.5000105@oracle.com>

Hi Erik,

This seems to be a potentially very disruptive change. Argument 
management is in general very fragile and easily broken, so major 
changes like this are difficult to validate because it can be the 
combinations of different args that cause the problem.

On 30/10/2012 12:29 AM, Erik Helin wrote:
> the webrev can be found at:
>
> http://cr.openjdk.java.net/~jwilhelm/7198334/webrev/
>
> Summary:
> The bug existed because the function 'Arguments::parse' changed the
> value of the flags 'UseNUMAInterleaving' and 'MinHeapDeltaBytes'
> depending on the value of the flag 'UseNUMA'.
>
> The problem was that the function 'os::init_2' checks if NUMA is
> supported on the system, and if it is not supported, sets 'UseNUMA' to
> 'false'.
>
> Since 'Arguments::parse' is called before 'os::init_2' in the function
> 'Threads::create_vm', the result was that 'UseNUMA' was set to false and
> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly
> modified.

Could we not simply adjust UseNUMAInterleaving and MinHeapDeltaBytes at 
the same time as setting UseNUMA to false? Or move the setting of 
UseNUMA to false out of os::init_2 into an earlier function - os::init 
perhaps?

> The fix splits the function 'Arguments::parse' into three functions:
> - 'Arguments::parse' now only parses the arguments.
> - 'Arguments::adjust_before_os' adjusts the flags that must be adjusted
> *before* 'os::init_after_parsing_flags'.
> - 'Arguments::adjust_after_os' adjusts the flags that must be adjusted
> *after* 'os::init_after_parsing_flags'.
>
> Note that three functions are necessary since the flag 'UseLargePages'
> has to be adjusted *before* 'os::init_2' is called.

I don't understand the comment about UseLargePages. But what you have 
done to deal with this single UseNUMA issue is not only move that piece 
of code (which is inside set_parallel_gc_flags()) but all of the GC flag 
setting that previously occurred *before* os::init_2() was called. 
Further you now have to verif that none of the option management that 
now happens before the GC flags are set in any way relies upon the 
settings of those GC flags!

This just seems too disruptive and difficult to test adequately.

> This change also renames 'os::init' to 'os::init_before_parsing_flags'
> and 'os::init_2' to 'os::init_after_parsing_args'. This was done to try
> to make the relationship between the functions in 'Arguments' and the
> functions in 'os' as clear as possible.

A little too verbose though I think. Maybe os::init_pre_args() and 
os::init_post_args() ? Though really the names are not that significant 
given the comments both at the call site and declaration site of the 
methods.

> Testing:
> JPRT

JPRT will barely test anything related to argument processing.

David
-----

>
> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal -version' on a
> system that does not support NUMA shows that 'UseNUMAInterleaving' and
> 'MinHeapDeltaBytes' now have correct values.
>
> Thanks,
> Erik

From david.holmes at oracle.com  Mon Oct 29 21:48:38 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Oct 2012 14:48:38 +1000
Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source
	code
In-Reply-To: <6E8A6F30-47EF-40F3-A26C-24A83B3A6369@oracle.com>
References: <508EB0F2.80408@oracle.com>
	<21484E86-B262-4581-8AEC-93DD737D8A28@oracle.com>
	<4F2212B0-ED56-43A9-A8BC-D0521769769E@oracle.com>
	<16596034-0B88-4742-A7FE-3B8B546DE759@oracle.com>
	<4B619AF9-2BB7-4878-AB2D-4B63E942831D@oracle.com>
	<6E8A6F30-47EF-40F3-A26C-24A83B3A6369@oracle.com>
Message-ID: <508F5C26.7040701@oracle.com>

Notwithstanding we may have to abandon this if the community is using 
the IA64 "support" that exists in the shared code ...

Are the SA changes consistent with what Yumin had proposed and is fixing 
under:

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

---

This change in the windows code needs closer examination:

-#ifdef _M_IA64
-#define __CPU__ ia64
-#elif _M_AMD64
-#define __CPU__ amd64
-#else
-#define __CPU__ i486
-#endif

while it appears that __CPU__ is not being used in our source code, it 
may be that this was needed to affect other headers and/or the compiler. 
This dates back a long way.

---

There are no makefile changes to remove ia64 settings. If we are going 
to do this then we should do it all.

Cheers,
David

On 30/10/2012 4:52 AM, Christian Thalinger wrote:
>
> On Oct 29, 2012, at 10:55 AM, Vladimir Kozlov<vladimir.kozlov at oracle.com>  wrote:
>
>>
>> On Oct 29, 2012, at 10:48 AM, Christian Thalinger wrote:
>>
>>> Sure:  http://cr.openjdk.java.net/~twisti/6518907
>>>
>>> Btw. the bug synopsis (which is called Summary in JIRA) is actually:
>>>
>>> 6518907: too many platform-specific ifdefs in source code
>>>
>>> -- Chris
>>>
>>> On Oct 29, 2012, at 10:35 AM, Vladimir Kozlov<vladimir.kozlov at oracle.com>  wrote:
>>>
>>>> Christian,
>>>>
>>>> Can you move web rev  to cr.openjdk so people outside can review it. We then can ask RH and SAP if they use that code.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On Oct 29, 2012, at 10:31 AM, Christian Thalinger wrote:
>>>>
>>>>>
>>>>> On Oct 29, 2012, at 9:38 AM, Morris Meyer<morris.meyer at oracle.com>  wrote:
>>>>>
>>>>>> Took a pass at purging the platform-specific IA64 refs throughout the source base.
>>>>>
>>>>> In general I think this is okay.  The only thing I'm worried is that maybe some defines or such may be used when compiling Zero on IA64.  Although I don't know if anyone is doing that.
>
> Apparently Debian is doing it:
>
> http://packages.debian.org/sid/ia64/openjdk-7-jre-headless
>
> -- Chris
>
>>>>>
>>>>> -- Chris
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>         --mm
>>>>>>
>>>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907
>>>>>> WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-6518907/
>>>>>
>>>>
>>>
>>
>

From staffan.larsen at oracle.com  Mon Oct 29 23:51:56 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 30 Oct 2012 07:51:56 +0100
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508E7F25.6080309@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>
	<508A7592.4070800@oracle.com>
	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>
	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>
	<508B23D8.2@oracle.com>
	<A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
	<508E7F25.6080309@oracle.com>
Message-ID: <75D2B9E5-EFAB-42F2-AC94-C995D74D46E0@oracle.com>

I took the liberty of pushing this including the changes on zero. I hope I didn't break anything.

/Staffan

On 29 okt 2012, at 14:05, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> 
> Staffan,
> I think this looks fine to me.  It appears that Roman Kennke rkennke at redhat.com is working on Zero, and has sent a set of changes to us to integrate.   Christian Thalinger is doing this. He hasn't changed bsd_zero with his change so there won't be any conflict.  He'll likely let you know if you (doubtfully) broke this.
> 
> Coleen
> 
> On 10/29/2012 5:30 AM, Staffan Larsen wrote:
>> Here's a version with the zero changes as well: http://cr.openjdk.java.net/~sla/8001619/webrev.02/
>> 
>> If it looks good, I'll push this version instead.
>> 
>> /Staffan
>> 
>> On 27 okt 2012, at 01:59, David Holmes <David.Holmes at oracle.com> wrote:
>> 
>>> On 26/10/2012 10:03 PM, Staffan Larsen wrote:
>>>> Oh... and new webrev at: http://cr.openjdk.java.net/~sla/8001619/webrev.01/
>>> Thumbs up.
>>> 
>>> But for completeness I would have liked to see the zero code cleaned up too. I'm not sure how the contact is. I'm tempted to say do it anyway as it seems simple enough and if it happens to break zero someone will shout and we do a fix. Otherwise the chances that this cleanup will get applied to the zero code seem very low.
>>> 
>>> David
>>> 
>>>> On 26 okt 2012, at 13:58, Staffan Larsen <staffan.larsen at oracle.com
>>>> <mailto:staffan.larsen at oracle.com>> wrote:
>>>> 
>>>>> On 26 okt 2012, at 13:35, David Holmes <David.Holmes at oracle.com
>>>>> <mailto:David.Holmes at oracle.com>> wrote:
>>>>> 
>>>>>> On 26/10/2012 8:47 PM, Staffan Larsen wrote:
>>>>>>> This is an attempt at cleaning up the source in src/os/bsd by
>>>>>>> removing the usage of _ALLBSD_SOURCE in these files. Since the
>>>>>>> define is always set when compiling these files it is not necessary
>>>>>>> to use it in the source files. The usage was originally added during
>>>>>>> the porting to make it easier to see changes against the base linux
>>>>>>> version.
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~sla/8001619/webrev.00/
>>>>>> Generally looks okay (though now I see some of the actual BSD code it
>>>>>> makes me a little nervous!). A couple of minor things:
>>>>> Thanks.
>>>>> 
>>>>>> os_bsd.cpp:
>>>>>> 
>>>>>> 977 }
>>>>>> 978 #elif
>>>>>> 
>>>>>> 3957 return true;
>>>>>> 3958 #elif
>>>>>> 3959 return false;
>>>>>> 
>>>>>> Shouldn't the elif's have become an else?
>>>>>> 
>>>>>> Ditto for os_bsd_x86.cpp:
>>>>>> 
>>>>>> 850 #elif
>>>>> You are right. I've fixed this.
>>>>> 
>>>>>> Also you can probably do the same thing for bsd_zero:
>>>>>> /src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp. Just check with the zero folk.
>>>>> I didn't touch the zero files since I wasn't sure who maintains it.
>>>>> I'm not sure how to build it so I didn't want to do changes.
>>>>> 
>>>>> /Staffan
>>>>> 
>>>>> 
>>>>>> David
>>>>>> -----
>>>>>> 
>>>>>>> Thanks,
>>>>>>> /Staffan
> 


From keith.mcguigan at oracle.com  Tue Oct 30 07:55:10 2012
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Tue, 30 Oct 2012 10:55:10 -0400
Subject: Default methods for jdk8: request for code review
In-Reply-To: <508E10D7.7070404@oracle.com>
References: <5075AC78.3030702@oracle.com> <508A96C6.1080207@oracle.com>
	<3BCECE5D-8B12-4B10-B2BE-E2F3B1001FD9@oracle.com>
	<508E10D7.7070404@oracle.com>
Message-ID: <B55028EB-0FBF-456D-ADC3-AAE6EFC4D991@oracle.com>


On Oct 29, 2012, at 1:15 AM, David Holmes wrote:

> Hi Keith,
> 
> The more I look at this the more questions that come to mind. :)
> 
> Can you expand on the rationale for using overpass methods instead of augmenting the existing method lookup procedures. I'm concerned about its impact on startup time - and given that we have not yet added all the default methods that will be added, nor do we know for certain which interfaces will get what methods, I don't think we can measure this yet.

It is certainly something we can look into in the future.  We will at some point need some sort of signature adapter with checkcasts in order to get from a callsite to a default method.  So something needs to be created.  Doing it lazily instead of ahead-of-time is something to look into, but a likely result of that is that we end up performing the generic analysis multiple times at different call sites and end up on losing some of the sharing -- doing it all at once may be more efficient since the parsing of generic signatures and some of the hierarchy analysis is effectively "reused".

> In LinkResolver::resolve_method we would previously bail out if the resolved_klass is in fact an interface. But now we will pass that interface to both lookup_method_in_klasses and lookup_method_in_interfaces. That sounds wrong - should the names of these methods be updated?

Yeah maybe we should.  I'll look into that.

> In instanceKlass.cpp in the new interface initialization section why do you refer to the "superclass initialization error"? Are we simply pretending that any failure here was actually a superclass failure? And if so, is that temporary?

I copied that code from the superclass initialization part, so it does the same thing as there.  I think the idea is that if we encounter an error during initialization, we save that exception and perform the notify.  Any exception that occurs during the notify is ignored and the initialization error is rethrown. 

--
- Keith

From volker.simonis at gmail.com  Tue Oct 30 07:54:31 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 30 Oct 2012 15:54:31 +0100
Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in
	source code
In-Reply-To: <508F5C26.7040701@oracle.com>
References: <508EB0F2.80408@oracle.com>
	<21484E86-B262-4581-8AEC-93DD737D8A28@oracle.com>
	<4F2212B0-ED56-43A9-A8BC-D0521769769E@oracle.com>
	<16596034-0B88-4742-A7FE-3B8B546DE759@oracle.com>
	<4B619AF9-2BB7-4878-AB2D-4B63E942831D@oracle.com>
	<6E8A6F30-47EF-40F3-A26C-24A83B3A6369@oracle.com>
	<508F5C26.7040701@oracle.com>
Message-ID: <CA+3eh12T3Hd2hu66KYFkbpuGPBE+ZoMARrFUoh5_p2TYhMTTkg@mail.gmail.com>

Hi,

thank you for remembering us:)

We at SAP are indeed using this code - at least most of it.

We don't support the SA at all, so the changes there will not affect
us (and I suppose they won't affect ZERO as well).

But most of the other changes are required for IA64 (e.g.
need_register_stack_bang() in compile.hpp.

I'm currently out of office and Thursday is public holiday in Germany
so probably there will not be a lot of folks in the offices at the end
of this week, but we would really appreciate if you'd give us some
more time to review this change. Maybe some of the arcane IA64 stuff
can be really removed, but I think most of it is still required for an
IA64 port to work.

Regards,
Volker

On Tue, Oct 30, 2012 at 5:48 AM, David Holmes <david.holmes at oracle.com> wrote:
> Notwithstanding we may have to abandon this if the community is using the
> IA64 "support" that exists in the shared code ...
>
> Are the SA changes consistent with what Yumin had proposed and is fixing
> under:
>
> https://jbs.oracle.com/bugs/browse/JDK-8000412
>
> ---
>
> This change in the windows code needs closer examination:
>
> -#ifdef _M_IA64
> -#define __CPU__ ia64
> -#elif _M_AMD64
> -#define __CPU__ amd64
> -#else
> -#define __CPU__ i486
> -#endif
>
> while it appears that __CPU__ is not being used in our source code, it may
> be that this was needed to affect other headers and/or the compiler. This
> dates back a long way.
>
> ---
>
> There are no makefile changes to remove ia64 settings. If we are going to do
> this then we should do it all.
>
> Cheers,
> David
>
>
> On 30/10/2012 4:52 AM, Christian Thalinger wrote:
>>
>>
>> On Oct 29, 2012, at 10:55 AM, Vladimir Kozlov<vladimir.kozlov at oracle.com>
>> wrote:
>>
>>>
>>> On Oct 29, 2012, at 10:48 AM, Christian Thalinger wrote:
>>>
>>>> Sure:  http://cr.openjdk.java.net/~twisti/6518907
>>>>
>>>> Btw. the bug synopsis (which is called Summary in JIRA) is actually:
>>>>
>>>> 6518907: too many platform-specific ifdefs in source code
>>>>
>>>> -- Chris
>>>>
>>>> On Oct 29, 2012, at 10:35 AM, Vladimir
>>>> Kozlov<vladimir.kozlov at oracle.com>  wrote:
>>>>
>>>>> Christian,
>>>>>
>>>>> Can you move web rev  to cr.openjdk so people outside can review it. We
>>>>> then can ask RH and SAP if they use that code.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On Oct 29, 2012, at 10:31 AM, Christian Thalinger wrote:
>>>>>
>>>>>>
>>>>>> On Oct 29, 2012, at 9:38 AM, Morris Meyer<morris.meyer at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Took a pass at purging the platform-specific IA64 refs throughout the
>>>>>>> source base.
>>>>>>
>>>>>>
>>>>>> In general I think this is okay.  The only thing I'm worried is that
>>>>>> maybe some defines or such may be used when compiling Zero on IA64.
>>>>>> Although I don't know if anyone is doing that.
>>
>>
>> Apparently Debian is doing it:
>>
>> http://packages.debian.org/sid/ia64/openjdk-7-jre-headless
>>
>> -- Chris
>>
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>         --mm
>>>>>>>
>>>>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907
>>>>>>> WEBREV -
>>>>>>> http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-6518907/
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From erik.x.helin at oracle.com  Tue Oct 30 08:14:32 2012
From: erik.x.helin at oracle.com (Erik Helin)
Date: Tue, 30 Oct 2012 16:14:32 +0100
Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA
	system
In-Reply-To: <508F497D.5000105@oracle.com>
References: <508E92C2.2080604@oracle.com> <508F497D.5000105@oracle.com>
Message-ID: <508FEED8.3040705@oracle.com>

Hi David,

thank you for reviewing this change!

Please see an updated webrev at:

http://cr.openjdk.java.net/~mgerdin/JDK-7198334/

I've responded inline.

On 10/30/2012 04:29 AM, David Holmes wrote:
> On 30/10/2012 12:29 AM, Erik Helin wrote:
>> Since 'Arguments::parse' is called before 'os::init_2' in the function
>> 'Threads::create_vm', the result was that 'UseNUMA' was set to false and
>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly
>> modified.
>
> Could we not simply adjust UseNUMAInterleaving and MinHeapDeltaBytes at
> the same time as setting UseNUMA to false? Or move the setting of
> UseNUMA to false out of os::init_2 into an earlier function - os::init
> perhaps?

We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in os::init_2 
which is responsible for setting UseNUMA to false. However, I don't 
think that os should adjust MinHeapDeltaBytes, which is a GC flag.

We can not move the setting of UseNUMA to os::init, because we don't 
want to try to load libnuma (on Linux) if UseNUMA is not set to true, 
which means that UseNUMA has to be parsed before os can check if it 
should load libnuma.

On 10/30/2012 04:29 AM, David Holmes wrote:
> I don't understand the comment about UseLargePages. But what you have
> done to deal with this single UseNUMA issue is not only move that piece
> of code (which is inside set_parallel_gc_flags()) but all of the GC flag
> setting that previously occurred *before* os::init_2() was called.
> Further you now have to verif that none of the option management that
> now happens before the GC flags are set in any way relies upon the
> settings of those GC flags!
>
> This just seems too disruptive and difficult to test adequately.

I agree, I moved too much functionality into Arguments::adjust_after_os.

I do not think that simply splitting Arguments::parse into two 
functions, Arguments::parse and Arguments::adjust_before_os is a 
disruptive change if Arguments::adjust_before_os ends up being called 
directly after Arguments::parse. In fact, this change is not needed, but 
I think it makes the code easier to understand.

With the new change, which only moves the check for UseNUMA into 
Arguments::ajdust_after_os, I don't think that this change is too 
disruptive either.

Please see the new webrev for more details.

On 10/30/2012 04:29 AM, David Holmes wrote:
>> This change also renames 'os::init' to 'os::init_before_parsing_flags'
>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done to try
>> to make the relationship between the functions in 'Arguments' and the
>> functions in 'os' as clear as possible.
>
> A little too verbose though I think. Maybe os::init_pre_args() and
> os::init_post_args() ? Though really the names are not that significant
> given the comments both at the call site and declaration site of the
> methods.

My idea was that the code should "speak for itself" and hopefully render 
the comments unnecessary, since comments sometimes can become outdated 
but code can't.

My idea was actually to remove the comments and just keep the verbose 
names, what do you think of this?

On 10/30/2012 04:29 AM, David Holmes wrote:
>> Testing:
>> JPRT
>
> JPRT will barely test anything related to argument processing.

Ok, thank you for this information. Can you recommend a way to test this 
change?

Thanks,
Erik

> David
> -----
>
>>
>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal -version' on a
>> system that does not support NUMA shows that 'UseNUMAInterleaving' and
>> 'MinHeapDeltaBytes' now have correct values.
>>
>> Thanks,
>> Erik

From vladimir.kozlov at oracle.com  Tue Oct 30 08:33:09 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 30 Oct 2012 08:33:09 -0700
Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in
	source code
In-Reply-To: <CA+3eh12T3Hd2hu66KYFkbpuGPBE+ZoMARrFUoh5_p2TYhMTTkg@mail.gmail.com>
References: <508EB0F2.80408@oracle.com>
	<21484E86-B262-4581-8AEC-93DD737D8A28@oracle.com>
	<4F2212B0-ED56-43A9-A8BC-D0521769769E@oracle.com>
	<16596034-0B88-4742-A7FE-3B8B546DE759@oracle.com>
	<4B619AF9-2BB7-4878-AB2D-4B63E942831D@oracle.com>
	<6E8A6F30-47EF-40F3-A26C-24A83B3A6369@oracle.com>
	<508F5C26.7040701@oracle.com>
	<CA+3eh12T3Hd2hu66KYFkbpuGPBE+ZoMARrFUoh5_p2TYhMTTkg@mail.gmail.com>
Message-ID: <D73DB298-3C4D-4E50-B4F6-5677ADB6B384@oracle.com>

Hi, Volker

We will wait your review. Have a good Holiday!

Regards,
Vladimir

On Oct 30, 2012, at 7:54 AM, Volker Simonis wrote:

> Hi,
> 
> thank you for remembering us:)
> 
> We at SAP are indeed using this code - at least most of it.
> 
> We don't support the SA at all, so the changes there will not affect
> us (and I suppose they won't affect ZERO as well).
> 
> But most of the other changes are required for IA64 (e.g.
> need_register_stack_bang() in compile.hpp.
> 
> I'm currently out of office and Thursday is public holiday in Germany
> so probably there will not be a lot of folks in the offices at the end
> of this week, but we would really appreciate if you'd give us some
> more time to review this change. Maybe some of the arcane IA64 stuff
> can be really removed, but I think most of it is still required for an
> IA64 port to work.
> 
> Regards,
> Volker
> 
> On Tue, Oct 30, 2012 at 5:48 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Notwithstanding we may have to abandon this if the community is using the
>> IA64 "support" that exists in the shared code ...
>> 
>> Are the SA changes consistent with what Yumin had proposed and is fixing
>> under:
>> 
>> https://jbs.oracle.com/bugs/browse/JDK-8000412
>> 
>> ---
>> 
>> This change in the windows code needs closer examination:
>> 
>> -#ifdef _M_IA64
>> -#define __CPU__ ia64
>> -#elif _M_AMD64
>> -#define __CPU__ amd64
>> -#else
>> -#define __CPU__ i486
>> -#endif
>> 
>> while it appears that __CPU__ is not being used in our source code, it may
>> be that this was needed to affect other headers and/or the compiler. This
>> dates back a long way.
>> 
>> ---
>> 
>> There are no makefile changes to remove ia64 settings. If we are going to do
>> this then we should do it all.
>> 
>> Cheers,
>> David
>> 
>> 
>> On 30/10/2012 4:52 AM, Christian Thalinger wrote:
>>> 
>>> 
>>> On Oct 29, 2012, at 10:55 AM, Vladimir Kozlov<vladimir.kozlov at oracle.com>
>>> wrote:
>>> 
>>>> 
>>>> On Oct 29, 2012, at 10:48 AM, Christian Thalinger wrote:
>>>> 
>>>>> Sure:  http://cr.openjdk.java.net/~twisti/6518907
>>>>> 
>>>>> Btw. the bug synopsis (which is called Summary in JIRA) is actually:
>>>>> 
>>>>> 6518907: too many platform-specific ifdefs in source code
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>> On Oct 29, 2012, at 10:35 AM, Vladimir
>>>>> Kozlov<vladimir.kozlov at oracle.com>  wrote:
>>>>> 
>>>>>> Christian,
>>>>>> 
>>>>>> Can you move web rev  to cr.openjdk so people outside can review it. We
>>>>>> then can ask RH and SAP if they use that code.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On Oct 29, 2012, at 10:31 AM, Christian Thalinger wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Oct 29, 2012, at 9:38 AM, Morris Meyer<morris.meyer at oracle.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Took a pass at purging the platform-specific IA64 refs throughout the
>>>>>>>> source base.
>>>>>>> 
>>>>>>> 
>>>>>>> In general I think this is okay.  The only thing I'm worried is that
>>>>>>> maybe some defines or such may be used when compiling Zero on IA64.
>>>>>>> Although I don't know if anyone is doing that.
>>> 
>>> 
>>> Apparently Debian is doing it:
>>> 
>>> http://packages.debian.org/sid/ia64/openjdk-7-jre-headless
>>> 
>>> -- Chris
>>> 
>>>>>>> 
>>>>>>> -- Chris
>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>>        --mm
>>>>>>>> 
>>>>>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907
>>>>>>>> WEBREV -
>>>>>>>> http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-6518907/
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 


From landonf at plausible.coop  Tue Oct 30 10:15:06 2012
From: landonf at plausible.coop (Landon Fuller)
Date: Tue, 30 Oct 2012 13:15:06 -0400
Subject: RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
In-Reply-To: <508E6E62.3080708@oracle.com>
References: <5C4C7F76-6A0E-44BB-8756-38263E5CF59C@oracle.com>	<508A7592.4070800@oracle.com>	<9DCEF065-8BFC-46F7-8537-6C5E8FBF69D3@oracle.com>	<D6672924-491F-4A35-B71D-3733AEF8EC37@oracle.com>	<508B23D8.2@oracle.com>	<A62A75DF-4255-4A28-B137-85F6BCA6EF5D@oracle.com>
	<508E673C.30902@oracle.com> <508E6E62.3080708@oracle.com>
Message-ID: <735516AE-6BA2-4991-969A-33C1CFE63043@plausible.coop>


On Oct 29, 2012, at 7:54 AM, Daniel D. Daugherty wrote:

> On 10/29/12 7:23 AM, David Holmes wrote:
>> On 29/10/2012 7:30 PM, Staffan Larsen wrote:
>>> Here's a version with the zero changes as well: http://cr.openjdk.java.net/~sla/8001619/webrev.02/
>>> 
>>> If it looks good, I'll push this version instead.
>> 
>> Some of the conditionals are puzzling to me given this was all done for the MacOSX port:
>> 
>> 326 #ifdef __APPLE__
>> ...
>> 331 #elif defined(__OpenBSD__)
>> ...
>> 342 #elif defined(_ALLBSD_SOURCE)
>> ...
>> 
>> I would have expected __APPLE__ to always be defined (else it is redundant everywhere else!), but then that would preclude the _ALLBSD_SOURCE code from being used.
> 
> The project that we (in Oracle) called the "MacOS X Port" project
> imported changes from the BSD Port project:
> 
>    http://hg.openjdk.java.net/bsd-port/bsd-port
> 
> and from the MacOS X Port project:
> 
>    http://hg.openjdk.java.net/macosx-port/macosx-port
> 
> so there are multiple "flavors" of BSD in the mix...

I'm probably the original author of much of the __APPLE__ code, predating even the OpenJDK bsd-port, back when the project was based on the SCSL and JRL source drops being patched by the BSDs.

As a general rule I relied on the BSD implementations where-ever possible, but there are numerous points where the code had to be specialized for Mac OS X in a significantly distinct manner the default BSD implementations. In cases such as the one referenced above, _ALLBSD_SOURCE provides the default common BSD implementation, with per-OS specialization in the case where implementation necessarily differed.

Causes for differentiation from the standard BSD code paths included thread handling (non-standard pthread*_np() functions, thread priority, thread suspension), signal handling (Darwin differs in the signals thrown for different conditions, both in terms of other BSDs, and on x86-32 vs x86-64, and required some code analysis to differentiate some signals), executable/shared library handling (dylib/macho vs. so/elf), etc.

FWIW,
-landonf

From christian.thalinger at oracle.com  Mon Oct 29 10:56:02 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Oct 2012 10:56:02 -0700
Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of
	dead nodes
In-Reply-To: <04038883-A951-4916-BA99-F52D71B4B928@oracle.com>
References: <508DF417.7090906@oracle.com>
	<04038883-A951-4916-BA99-F52D71B4B928@oracle.com>
Message-ID: <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com>

[This should be over at hotspot-comp-dev since it only touches C2 code.  BCC'ing hotspot-dev.]

On Oct 29, 2012, at 10:29 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Bharadwaj,
> 
> These changes look much better. Sorry, I suggested to add verify_live_node_count() method before but your current code don't need it, just use count_live_nodes_by_graph_walk(). An other note: without LogCompilation verification code should produce some info on tty.
> 
> Thanks,
> Vladimir
> 
> On Oct 28, 2012, at 8:12 PM, Bharadwaj Yadavalli wrote:
> 
>> I'd like to get a code review of the changes at http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_01/
>> 
>> These changes are made to keep an (almost) accurate running count of the reachable (live) flow graph nodes. This will result in a more realistic node count for various phases of C2 to decide on whether to proceed with optimizations or not. Prior to these changes, C2 bails out of compilation based on the number of nodes created which typically larger than the number of reachable (live) nodes.
>> 
>> I observed no significant degradation in C2 compilation time of all classes in rt.jar time due to these changes.

We still need to adjust MaxNodeLimit.  Maybe some JRuby or Nashorn benchmarks can help in getting really big methods.

src/share/vm/opto/compile.cpp:

+     _log->elem("node count before optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'",

I think the log element name needs to have _'s so we can match it (if we want to):

+     _log->elem("node_count_before_optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'",

-- Chris

>> 
>> Thanks,
>> 
>> Bharadwaj
>> 
> 


From jiangli.zhou at oracle.com  Tue Oct 30 11:38:57 2012
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 30 Oct 2012 11:38:57 -0700
Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing
	on armsflt
In-Reply-To: <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com>
References: <5089C7E1.2040206@oracle.com>
	<7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com>
	<5089D6D0.3070909@oracle.com>
	<5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com>
Message-ID: <50901EC1.3080506@oracle.com>

Hi Chris,

Here is the updated webrev with added '-XX:+IgnoreUnrecognizedVMOptions 
-XX:-VerifyDependencies' options and timeout setting for the following 
tests:

   test.java.lang.invoke.RicochetTest
   test.java.lang.invoke.BigArityTest
   test.java.lang.invoke.MethodHandlesTest
   test.java.lang.invoke.CallSiteTest

http://cr.openjdk.java.net/~jiangli/7197210/webrev.01/

Thanks,

Jiangli

From alejandro.murillo at oracle.com  Tue Oct 30 12:47:44 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Tue, 30 Oct 2012 19:47:44 +0000
Subject: hg: hsx/hsx24/hotspot: 36 new changesets
Message-ID: <20121030194859.D964747688@hg.openjdk.java.net>

Changeset: 62c7660a9824
Author:    asaha
Date:      2012-04-17 14:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/62c7660a9824

Merge

! .hgtags

Changeset: 8d07f4d6312d
Author:    asaha
Date:      2012-04-19 09:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8d07f4d6312d

Merge

! .hgtags

Changeset: e7c2c0f5a630
Author:    asaha
Date:      2012-05-29 14:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e7c2c0f5a630

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/runtime/arguments.cpp

Changeset: 5062377a1189
Author:    asaha
Date:      2012-06-01 08:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5062377a1189

Merge

! .hgtags
! make/hotspot_version

Changeset: b4743ffd4d88
Author:    asaha
Date:      2012-06-01 10:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b4743ffd4d88

Merge

! .hgtags

Changeset: c24fcc1c0443
Author:    kvn
Date:      2012-05-23 12:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c24fcc1c0443

7158801: Improve VM CompileOnly option
Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file.
Reviewed-by: never

! src/share/vm/compiler/compilerOracle.cpp

Changeset: 89642d837dd0
Author:    asaha
Date:      2012-06-01 18:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/89642d837dd0

Merge


Changeset: 680f32d8cb81
Author:    kamg
Date:      2012-06-08 12:49 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/680f32d8cb81

7158804: Improve config file parsing
Summary: Check buffer length when reading
Reviewed-by: dholmes, dcubed

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp
+ test/runtime/7158804/Test7158804.sh

Changeset: 68b65652a8d0
Author:    kvn
Date:      2012-06-18 09:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/68b65652a8d0

7158807: Revise stack management with volatile call sites
Summary: Add missing stack banging into method handle assebly code and throw a StackOverflowError.
Reviewed-by: jrose, twisti

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
+ test/compiler/7158807/Test7158807.java

Changeset: 13a7c97f9e9a
Author:    asaha
Date:      2012-06-25 09:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/13a7c97f9e9a

Merge

! .hgtags
! make/hotspot_version

Changeset: b66bb0e3224f
Author:    asaha
Date:      2012-06-26 12:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b66bb0e3224f

7179908: Fork hs23.3 hsx from hs22.2 for jdk7u7 and reinitialize build number
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 488d62182543
Author:    katleman
Date:      2012-06-28 11:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/488d62182543

Added tag jdk7u7-b01 for changeset b66bb0e3224f

! .hgtags

Changeset: 2111880a148e
Author:    asaha
Date:      2012-07-09 12:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2111880a148e

Merge

! .hgtags
! make/hotspot_version

Changeset: 279bd24edadb
Author:    asaha
Date:      2012-07-18 23:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/279bd24edadb

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 6f46f46b0b43
Author:    asaha
Date:      2012-08-02 11:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6f46f46b0b43

Merge

! .hgtags

Changeset: ca6943c94e60
Author:    asaha
Date:      2012-08-07 13:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ca6943c94e60

Merge

! .hgtags

Changeset: 42c555420ebf
Author:    katleman
Date:      2012-08-08 12:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/42c555420ebf

Added tag jdk7u7-b02 for changeset ca6943c94e60

! .hgtags

Changeset: 552c03cbe67f
Author:    asaha
Date:      2012-08-10 14:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/552c03cbe67f

Merge

! .hgtags

Changeset: b828fd563f6c
Author:    asaha
Date:      2012-08-13 15:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b828fd563f6c

Merge

! .hgtags

Changeset: 6b9db7216dd4
Author:    katleman
Date:      2012-09-07 12:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6b9db7216dd4

Added tag jdk7u7-b11 for changeset f1551c70c7f5

! .hgtags

Changeset: 35a0937354a9
Author:    katleman
Date:      2012-09-10 13:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/35a0937354a9

Added tag jdk7u7-b31 for changeset 6b9db7216dd4

! .hgtags

Changeset: ff22dd0e65ae
Author:    asaha
Date:      2012-09-11 12:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ff22dd0e65ae

Merge

! .hgtags
! make/hotspot_version

Changeset: e043d96d767d
Author:    asaha
Date:      2012-08-24 11:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e043d96d767d

7189136: Fork hs23.5 hsx from hs23.4 for jdk7u9 and reinitialize build number
Reviewed-by: amurillo

! make/hotspot_version

Changeset: bfabc657b2a9
Author:    katleman
Date:      2012-09-13 11:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bfabc657b2a9

Added tag jdk7u9-b03 for changeset e043d96d767d

! .hgtags

Changeset: 13561990b5dc
Author:    asaha
Date:      2012-09-19 13:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/13561990b5dc

7199645: Increment build # of hs23.5 to b02
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 63ff4604e787
Author:    kvn
Date:      2012-09-19 21:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/63ff4604e787

7198606: Improve VM optimization
Reviewed-by: roland, twisti

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

Changeset: ed42837374ac
Author:    asaha
Date:      2012-09-19 21:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ed42837374ac

7199669: Update tags in .hgtags file for CPU release rename
Reviewed-by: jcoomes

! .hgtags

Changeset: 67e2c717c6c1
Author:    katleman
Date:      2012-09-20 14:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/67e2c717c6c1

Added tag jdk7u9-b04 for changeset ed42837374ac

! .hgtags

Changeset: da4aa289ac10
Author:    asaha
Date:      2012-09-24 12:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/da4aa289ac10

7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match.
Summary: moveed this testcase to test/closed
Reviewed-by: coleenp

- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: d2888fa87e9c
Author:    katleman
Date:      2012-09-25 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d2888fa87e9c

Added tag jdk7u9-b05 for changeset da4aa289ac10

! .hgtags

Changeset: cd9ffcd9523b
Author:    katleman
Date:      2012-08-17 11:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cd9ffcd9523b

Added tag jdk7u6-b31 for changeset 7566374c3c89

! .hgtags

Changeset: b407d109571f
Author:    asaha
Date:      2012-09-13 18:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b407d109571f

Merge

! .hgtags

Changeset: 8eaa45ed5f80
Author:    asaha
Date:      2012-10-12 12:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8eaa45ed5f80

Merge

! .hgtags

Changeset: 2feb69f1f09f
Author:    asaha
Date:      2012-10-18 22:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2feb69f1f09f

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/runtime/arguments.cpp
- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: b4da4e577c99
Author:    amurillo
Date:      2012-10-30 10:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b4da4e577c99

Merge

! .hgtags
- agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java
! make/hotspot_version
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
! src/share/vm/compiler/compilerOracle.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp
! src/share/vm/opto/loopTransform.cpp
- src/share/vm/prims/methodHandleWalk.cpp
- src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: 0601ca30c7b4
Author:    amurillo
Date:      2012-10-30 10:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0601ca30c7b4

Added tag hs24-b24 for changeset b4da4e577c99

! .hgtags


From alejandro.murillo at oracle.com  Tue Oct 30 15:13:28 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Tue, 30 Oct 2012 22:13:28 +0000
Subject: hg: hsx/hsx24/hotspot: 8001662: new hotspot build - hs24-b25
Message-ID: <20121030221333.5B3714768F@hg.openjdk.java.net>

Changeset: d3de822fbedd
Author:    amurillo
Date:      2012-10-30 11:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d3de822fbedd

8001662: new hotspot build - hs24-b25
Reviewed-by: jcoomes

! make/hotspot_version


From david.holmes at oracle.com  Tue Oct 30 18:49:43 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 Oct 2012 11:49:43 +1000
Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA
	system
In-Reply-To: <508FEED8.3040705@oracle.com>
References: <508E92C2.2080604@oracle.com> <508F497D.5000105@oracle.com>
	<508FEED8.3040705@oracle.com>
Message-ID: <509083B7.9040309@oracle.com>

Hi Erik,

On 31/10/2012 1:14 AM, Erik Helin wrote:
> Please see an updated webrev at:
>
> http://cr.openjdk.java.net/~mgerdin/JDK-7198334/

Okay - general restructure is much more palatable.

> I've responded inline.

As have I.

> On 10/30/2012 04:29 AM, David Holmes wrote:
>> On 30/10/2012 12:29 AM, Erik Helin wrote:
>>> Since 'Arguments::parse' is called before 'os::init_2' in the function
>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to false and
>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly
>>> modified.
>>
>> Could we not simply adjust UseNUMAInterleaving and MinHeapDeltaBytes at
>> the same time as setting UseNUMA to false? Or move the setting of
>> UseNUMA to false out of os::init_2 into an earlier function - os::init
>> perhaps?
>
> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in os::init_2
> which is responsible for setting UseNUMA to false. However, I don't
> think that os should adjust MinHeapDeltaBytes, which is a GC flag.

Ok, but in a similar style to what you have introduced, the os::init_2() 
code could simply call Arguments::adjust_gc_args() (or some such name).

That said I don't think the factoring of the changes into 
adjust_parallel_gc_flags_after_os() is warranted in the current 
proposal. It isn't being called from multiple places, nor from any 
Arguments client, so there's really no need to expand the Arguments API 
this way.

> We can not move the setting of UseNUMA to os::init, because we don't
> want to try to load libnuma (on Linux) if UseNUMA is not set to true,
> which means that UseNUMA has to be parsed before os can check if it
> should load libnuma.

Fair enough.

<snip>
> I agree, I moved too much functionality into Arguments::adjust_after_os.
>
> I do not think that simply splitting Arguments::parse into two
> functions, Arguments::parse and Arguments::adjust_before_os is a
> disruptive change if Arguments::adjust_before_os ends up being called
> directly after Arguments::parse. In fact, this change is not needed, but
> I think it makes the code easier to understand.

I don't think it is completely clear what changes can be done in parse 
versus what have to be deferred to adjust_before. So in my view this 
split does not directly aid understandability. I do understand that as a 
newcomer to the codebase this changes aids your understanding of the code.

 From a pragmatic perspective such changes are highly subjective and 
they add "noise" to the reviewing process.

> With the new change, which only moves the check for UseNUMA into
> Arguments::ajdust_after_os, I don't think that this change is too
> disruptive either.

Restricting the movement to only the code that needs moving is good.

> Please see the new webrev for more details.
>
> On 10/30/2012 04:29 AM, David Holmes wrote:
>>> This change also renames 'os::init' to 'os::init_before_parsing_flags'
>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done to try
>>> to make the relationship between the functions in 'Arguments' and the
>>> functions in 'os' as clear as possible.
>>
>> A little too verbose though I think. Maybe os::init_pre_args() and
>> os::init_post_args() ? Though really the names are not that significant
>> given the comments both at the call site and declaration site of the
>> methods.
>
> My idea was that the code should "speak for itself" and hopefully render
> the comments unnecessary, since comments sometimes can become outdated
> but code can't.

I am not a fan of "code speaking for itself" if the code "talks too 
much" - that is why languages have comments. Speaking belongs in 
comments. Code should be clear without being overly verbose, yet 
succinct without being cryptic. And code can certainly become outdated 
if that code is the name of a method. If the role of the method expands 
then it is better to adapt a comment than to revise an API to rename a 
method and update all callsites!

> My idea was actually to remove the comments and just keep the verbose
> names, what do you think of this?

I do not support that. This is highly subjective of course, but your 
changes fall beyond where I draw my line. :)

If you did not do this renaming your webrev would be exceedingly short 
compared to the current webrev, and your changes would only touch on GC 
related bits of code. The renaming affects the OS API and that is 
general runtime code. So I will defer to Karen as the owner of the 
runtime code.

Cheers,
David


>
> On 10/30/2012 04:29 AM, David Holmes wrote:
>>> Testing:
>>> JPRT
>>
>> JPRT will barely test anything related to argument processing.
>
> Ok, thank you for this information. Can you recommend a way to test this
> change?
>
> Thanks,
> Erik
>
>> David
>> -----
>>
>>>
>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal -version' on a
>>> system that does not support NUMA shows that 'UseNUMAInterleaving' and
>>> 'MinHeapDeltaBytes' now have correct values.
>>>
>>> Thanks,
>>> Erik

From zhengyu.gu at oracle.com  Wed Oct 31 09:12:17 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Wed, 31 Oct 2012 12:12:17 -0400
Subject: Code review request: NMT: assertion failed: assert(rec->addr() +
	rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp
Message-ID: <50914DE1.9050305@oracle.com>

NMT did not allow overlapped commit on memory regions, which is 
incorrect. Committing overlapped memory regions should be allowed, as 
long as the regions are within a reserved region.

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

Thanks,

-Zhengyu

From staffan.larsen at oracle.com  Wed Oct 31 13:59:18 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 31 Oct 2012 21:59:18 +0100
Subject: RFR: 8002078: hs_err_pid file should report full JDK version string
Message-ID: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>

Please review the following change to the crash output. Currently when hotspot crashes the output contains:

# JRE version: Java(TM) SE Runtime Environment (8.0) 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops) 

With the same installation "java -version" reports: 

Java(TM) SE Runtime Environment (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) 
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20, mixed mode) 

The first output above should be changed to look like: 

# JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)

http://cr.openjdk.java.net/~sla/8002078/webrev.01/

Thanks,
/Staffan

From vladimir.kozlov at oracle.com  Wed Oct 31 14:14:56 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 31 Oct 2012 14:14:56 -0700
Subject: RFR: 8002078: hs_err_pid file should report full JDK version
	string
In-Reply-To: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
References: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
Message-ID: <509194D0.3030306@oracle.com>

Looks good. Thank you for fixing this.

Vladimir

Staffan Larsen wrote:
> Please review the following change to the crash output. Currently when hotspot crashes the output contains:
> 
> # JRE version: Java(TM) SE Runtime Environment (8.0) 
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops) 
> 
> With the same installation "java -version" reports: 
> 
> Java(TM) SE Runtime Environment (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) 
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20, mixed mode) 
> 
> The first output above should be changed to look like: 
> 
> # JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) 
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)
> 
> http://cr.openjdk.java.net/~sla/8002078/webrev.01/
> 
> Thanks,
> /Staffan

From krystal.mo at oracle.com  Wed Oct 31 14:24:13 2012
From: krystal.mo at oracle.com (Krystal Mo)
Date: Thu, 01 Nov 2012 05:24:13 +0800
Subject: RFR: 8002078: hs_err_pid file should report full JDK version
	string
In-Reply-To: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
References: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
Message-ID: <509196FD.4020609@oracle.com>

Hi Staffan,

Looks good to me. This is helpful especially when dealing with nightlies.

But I wonder if it's better to fold get_java_runtime_name() and 
get_java_runtime_version() into one, something like 
set_java_runtime_info(), since these two functions are mostly doing the 
same thing.
I'm okay either way, the choice is up to you :-)

Regards,
Kris

On 2012/11/1 4:59, Staffan Larsen wrote:
> Please review the following change to the crash output. Currently when hotspot crashes the output contains:
>
> # JRE version: Java(TM) SE Runtime Environment (8.0)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)
>
> With the same installation "java -version" reports:
>
> Java(TM) SE Runtime Environment (build 1.8.0-internal-staffan_2012_10_09_15_30-b00)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20, mixed mode)
>
> The first output above should be changed to look like:
>
> # JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-staffan_2012_10_09_15_30-b00)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)
>
> http://cr.openjdk.java.net/~sla/8002078/webrev.01/
>
> Thanks,
> /Staffan

From serguei.spitsyn at oracle.com  Wed Oct 31 15:03:52 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 31 Oct 2012 15:03:52 -0700
Subject: RFR: 8002078: hs_err_pid file should report full JDK version
	string
In-Reply-To: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
References: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
Message-ID: <5091A048.1000005@oracle.com>

Looks good.

Thanks,
Serguei

On 10/31/12 1:59 PM, Staffan Larsen wrote:
> Please review the following change to the crash output. Currently when hotspot crashes the output contains:
>
> # JRE version: Java(TM) SE Runtime Environment (8.0)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)
>
> With the same installation "java -version" reports:
>
> Java(TM) SE Runtime Environment (build 1.8.0-internal-staffan_2012_10_09_15_30-b00)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20, mixed mode)
>
> The first output above should be changed to look like:
>
> # JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-staffan_2012_10_09_15_30-b00)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)
>
> http://cr.openjdk.java.net/~sla/8002078/webrev.01/
>
> Thanks,
> /Staffan


From david.holmes at oracle.com  Wed Oct 31 18:32:38 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 01 Nov 2012 11:32:38 +1000
Subject: Code review request: NMT: assertion failed: assert(rec->addr()
	+ rec->size() <= cur->base()) failed: Can not overlap in
	memSnapshot.cpp
In-Reply-To: <50914DE1.9050305@oracle.com>
References: <50914DE1.9050305@oracle.com>
Message-ID: <5091D136.8000801@oracle.com>

On 1/11/2012 2:12 AM, Zhengyu Gu wrote:
> NMT did not allow overlapped commit on memory regions, which is
> incorrect. Committing overlapped memory regions should be allowed, as
> long as the regions are within a reserved region.

So the overlapping stacks that were detected is perfectly valid?

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

The renaming from contains_xx to contain_xx is not correct. "contains" 
is the correct form to use, and "overlaps" rather than "overlap".

Why the variable rename in VMMemPointerIterator::add_reserved_region? 
Given it is initialized from current() then 'cur' seems quite 
acceptable. Otherwise maybe it is current() that has the wrong name? The 
renaming generates a lot of noise in the webrev - it is hard to see the 
actual substantive changes that were made.

Cheers,
David


> Thanks,
>
> -Zhengyu

From david.holmes at oracle.com  Wed Oct 31 19:03:39 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 01 Nov 2012 12:03:39 +1000
Subject: RFR: 8002078: hs_err_pid file should report full JDK version
	string
In-Reply-To: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
References: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com>
Message-ID: <5091D87B.1000402@oracle.com>

Hi Staffan,

thread.cpp - Minor typo:

  // extract the JRE vesion


Otherwise looks fine. I don't see any way to reduce the duplication that 
is obviously better.

David

On 1/11/2012 6:59 AM, Staffan Larsen wrote:
> Please review the following change to the crash output. Currently when hotspot crashes the output contains:
>
> # JRE version: Java(TM) SE Runtime Environment (8.0)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)
>
> With the same installation "java -version" reports:
>
> Java(TM) SE Runtime Environment (build 1.8.0-internal-staffan_2012_10_09_15_30-b00)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20, mixed mode)
>
> The first output above should be changed to look like:
>
> # JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-staffan_2012_10_09_15_30-b00)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops)
>
> http://cr.openjdk.java.net/~sla/8002078/webrev.01/
>
> Thanks,
> /Staffan