From daniel.daugherty at oracle.com  Wed Sep  1 10:55:47 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 01 Sep 2010 11:55:47 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C75434B.7080307@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com>
Message-ID: <4C7E93A3.1030401@oracle.com>

I'm finally getting back to this thread. Since I'm also applying
Matthias' changes to the Solaris sa.makefile, I figured I would
send out a webrev:

http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/

Kelly and Christian, can I get re-reviews from the two of you?

Matthias, can you verify that I got the Solaris port of your
changes correct?

Thanks, in advance, for any reviews...

Dan


On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>  
>>> Thanks for the reviews Kelly and Christian.
>>>
>>> Is there a reason to not apply these changes to the solaris and
>>> windows versions also? I haven't looked yet, but I figured I
>>> would ask...
>>>     
>>
>> Yeah, I also thought about this for Solaris and it should work there as
>> on Linux.  Don't know about Windows, though.
>>   
>
> Looks like Windows already uses a "make" construct instead of running
> into the shell command line limitation:
>
>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
> <snip>
>
>>         @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>> $(SA_CLASSPATH) -so
>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>         @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>> $(SA_CLASSPATH) -so
>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>
> I also think this is an "nmake" Makefile instead of a GNU Makefile.
> I think I'll look at applying the changes to the Solaris Makefile and
> leave the Windows stuff alone :-)
>
> Dan
>
>
>

From tom.rodriguez at oracle.com  Wed Sep  1 11:17:50 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 1 Sep 2010 11:17:50 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C7E93A3.1030401@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
Message-ID: <D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>

Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.

tom

On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:

> I'm finally getting back to this thread. Since I'm also applying
> Matthias' changes to the Solaris sa.makefile, I figured I would
> send out a webrev:
> 
> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
> 
> Kelly and Christian, can I get re-reviews from the two of you?
> 
> Matthias, can you verify that I got the Solaris port of your
> changes correct?
> 
> Thanks, in advance, for any reviews...
> 
> Dan
> 
> 
> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>> 
>>>> Thanks for the reviews Kelly and Christian.
>>>> 
>>>> Is there a reason to not apply these changes to the solaris and
>>>> windows versions also? I haven't looked yet, but I figured I
>>>> would ask...
>>>>    
>>> 
>>> Yeah, I also thought about this for Solaris and it should work there as
>>> on Linux.  Don't know about Windows, though.
>>>  
>> 
>> Looks like Windows already uses a "make" construct instead of running
>> into the shell command line limitation:
>> 
>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>> <snip>
>> 
>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>> 
>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>> I think I'll look at applying the changes to the Solaris Makefile and
>> leave the Windows stuff alone :-)
>> 
>> Dan
>> 
>> 
>> 


From kelly.ohair at oracle.com  Wed Sep  1 11:58:09 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 1 Sep 2010 11:58:09 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C7E93A3.1030401@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
Message-ID: <C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>

Looks fine, although I really hate all these $(QUIETLY) uses.

Why would the "rm" in the clean rule not be quiet, but all these  
critical build lines be quiet?

The RE and others have a hard time tracking down build failures when  
the rules are quiet,
makes the build logs less than useful.

-kto

On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:

> I'm finally getting back to this thread. Since I'm also applying
> Matthias' changes to the Solaris sa.makefile, I figured I would
> send out a webrev:
>
> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>
> Kelly and Christian, can I get re-reviews from the two of you?
>
> Matthias, can you verify that I got the Solaris port of your
> changes correct?
>
> Thanks, in advance, for any reviews...
>
> Dan
>
>
> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>
>>>> Thanks for the reviews Kelly and Christian.
>>>>
>>>> Is there a reason to not apply these changes to the solaris and
>>>> windows versions also? I haven't looked yet, but I figured I
>>>> would ask...
>>>>
>>>
>>> Yeah, I also thought about this for Solaris and it should work  
>>> there as
>>> on Linux.  Don't know about Windows, though.
>>>
>>
>> Looks like Windows already uses a "make" construct instead of running
>> into the shell command line limitation:
>>
>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>> <snip>
>>
>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>> (SA_CLASSPATH) -so
>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>> (SA_CLASSPATH) -so
>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>
>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>> I think I'll look at applying the changes to the Solaris Makefile and
>> leave the Windows stuff alone :-)
>>
>> Dan
>>
>>
>>


From vladimir.kozlov at oracle.com  Wed Sep  1 16:05:40 2010
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Wed, 01 Sep 2010 23:05:40 +0000
Subject: hg: jdk7/hotspot/hotspot: 7 new changesets
Message-ID: <20100901230555.BCAB747635@hg.openjdk.java.net>

Changeset: 14b92b91f460
Author:    kvn
Date:      2010-08-26 11:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/14b92b91f460

6976400: "Meet Not Symmetric"
Summary: Use NULL as klass for TypeAryPtr::RANGE. Add klass verification into TypeAryPtr ctor.
Reviewed-by: never

! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp

Changeset: 0878d7bae69f
Author:    twisti
Date:      2010-08-27 01:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0878d7bae69f

6961697: move nmethod constants section before instruction section
Summary: This is a preparation for 6961690.
Reviewed-by: kvn, never

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp

Changeset: d6f45b55c972
Author:    never
Date:      2010-08-27 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d6f45b55c972

4809552: Optimize Arrays.fill(...)
Reviewed-by: kvn

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! 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/share/vm/includeDB_compiler2
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 14197af1010e
Author:    never
Date:      2010-08-27 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/14197af1010e

Merge

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

Changeset: 114e6b93e9e1
Author:    kvn
Date:      2010-08-30 11:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/114e6b93e9e1

6980978: assert(mt == t->xmeet(this)) failed: meet not commutative
Summary: Fix code in TypeAryPtr::xmeet() for constant array.
Reviewed-by: never

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

Changeset: 02f0a9b6f654
Author:    never
Date:      2010-08-30 17:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/02f0a9b6f654

6969586: OptimizeStringConcat: SIGSEGV in LoadNode::Value()
Reviewed-by: kvn

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

Changeset: dee553c74493
Author:    never
Date:      2010-09-01 00:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dee553c74493

Merge



From christian.thalinger at oracle.com  Thu Sep  2 00:22:39 2010
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 02 Sep 2010 09:22:39 +0200
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>
	<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>
	<4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook>
	<4C751B5C.4020500@oracle.com> <4C753E38.8070208@oracle.com>
	<1282752683.32311.4.camel@macbook> <4C75434B.7080307@oracle.com>
	<4C7E93A3.1030401@oracle.com>
	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
Message-ID: <1283412159.16375.419.camel@macbook>

On Wed, 2010-09-01 at 11:17 -0700, Tom Rodriguez wrote:
> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?

I agree.  The changes look good.  -- Christian


From doko at ubuntu.com  Thu Sep  2 01:06:50 2010
From: doko at ubuntu.com (Matthias Klose)
Date: Thu, 02 Sep 2010 10:06:50 +0200
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>
Message-ID: <4C7F5B1A.5000003@ubuntu.com>

On 01.09.2010 20:58, Kelly O'Hair wrote:
> Looks fine, although I really hate all these $(QUIETLY) uses.
>
> Why would the "rm" in the clean rule not be quiet, but all these critical build
> lines be quiet?

I don't like quiet makes either, but I didn't want to change unrelated things in 
the patch. If the $(QUIETLY) rm is needed for consistencey, fine with me.

> The RE and others have a hard time tracking down build failures when the rules
> are quiet,
> makes the build logs less than useful.
>
> -kto
>
> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>
>> I'm finally getting back to this thread. Since I'm also applying
>> Matthias' changes to the Solaris sa.makefile, I figured I would
>> send out a webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>
>> Kelly and Christian, can I get re-reviews from the two of you?
>>
>> Matthias, can you verify that I got the Solaris port of your
>> changes correct?

this looks ok to me.

>> Thanks, in advance, for any reviews...
>>
>> Dan
>>
>>
>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>
>>>>> Thanks for the reviews Kelly and Christian.
>>>>>
>>>>> Is there a reason to not apply these changes to the solaris and
>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>> would ask...
>>>>>
>>>>
>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>> on Linux. Don't know about Windows, though.
>>>>
>>>
>>> Looks like Windows already uses a "make" construct instead of running
>>> into the shell command line limitation:
>>>
>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>> <snip>
>>>
>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>
>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>> I think I'll look at applying the changes to the Solaris Makefile and
>>> leave the Windows stuff alone :-)
>>>
>>> Dan
>>>
>>>
>>>
>


From kelly.ohair at oracle.com  Thu Sep  2 09:40:38 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 2 Sep 2010 09:40:38 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C7F5B1A.5000003@ubuntu.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>
	<4C7F5B1A.5000003@ubuntu.com>
Message-ID: <09109B10-9079-4A48-BB94-EED1724FC620@oracle.com>


On Sep 2, 2010, at 1:06 AM, Matthias Klose wrote:

> On 01.09.2010 20:58, Kelly O'Hair wrote:
>> Looks fine, although I really hate all these $(QUIETLY) uses.
>>
>> Why would the "rm" in the clean rule not be quiet, but all these  
>> critical build
>> lines be quiet?
>
> I don't like quiet makes either, but I didn't want to change  
> unrelated things in the patch. If the $(QUIETLY) rm is needed for  
> consistencey, fine with me.

It's ok, I'd rather leave it 'as is' than add more $(QUIETLY) uses.  I  
was just making a point about
quiet usage.  ;^)

The changes looks fine.

-kto

>
>> The RE and others have a hard time tracking down build failures  
>> when the rules
>> are quiet,
>> makes the build logs less than useful.
>>
>> -kto
>>
>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>
>>> I'm finally getting back to this thread. Since I'm also applying
>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>> send out a webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>
>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>
>>> Matthias, can you verify that I got the Solaris port of your
>>> changes correct?
>
> this looks ok to me.
>
>>> Thanks, in advance, for any reviews...
>>>
>>> Dan
>>>
>>>
>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>
>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>
>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>> would ask...
>>>>>>
>>>>>
>>>>> Yeah, I also thought about this for Solaris and it should work  
>>>>> there as
>>>>> on Linux. Don't know about Windows, though.
>>>>>
>>>>
>>>> Looks like Windows already uses a "make" construct instead of  
>>>> running
>>>> into the shell command line limitation:
>>>>
>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>> <snip>
>>>>
>>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>> (SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>> (SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>
>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>> I think I'll look at applying the changes to the Solaris Makefile  
>>>> and
>>>> leave the Windows stuff alone :-)
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>
>


From daniel.daugherty at oracle.com  Fri Sep  3 09:23:52 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Sep 2010 10:23:52 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
Message-ID: <4C812118.8020407@oracle.com>

Tom,

That makes a lot of sense! I'll take a look at making that tweak.

Dan


On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>
> tom
>
> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>
>   
>> I'm finally getting back to this thread. Since I'm also applying
>> Matthias' changes to the Solaris sa.makefile, I figured I would
>> send out a webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>
>> Kelly and Christian, can I get re-reviews from the two of you?
>>
>> Matthias, can you verify that I got the Solaris port of your
>> changes correct?
>>
>> Thanks, in advance, for any reviews...
>>
>> Dan
>>
>>
>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>     
>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>       
>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>
>>>>         
>>>>> Thanks for the reviews Kelly and Christian.
>>>>>
>>>>> Is there a reason to not apply these changes to the solaris and
>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>> would ask...
>>>>>    
>>>>>           
>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>> on Linux.  Don't know about Windows, though.
>>>>  
>>>>         
>>> Looks like Windows already uses a "make" construct instead of running
>>> into the shell command line limitation:
>>>
>>>       
>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>         
>>> <snip>
>>>
>>>       
>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>         
>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>> I think I'll look at applying the changes to the Solaris Makefile and
>>> leave the Windows stuff alone :-)
>>>
>>> Dan
>>>
>>>
>>>
>>>       
>
>   

From daniel.daugherty at oracle.com  Fri Sep  3 09:25:53 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Sep 2010 10:25:53 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>
Message-ID: <4C812191.9070806@oracle.com>

Thanks for the "looks fine" part! I think I'll take a pass on
trying to address the $(QUIETLY) issue in this bug fix.

Dan



On 9/1/2010 12:58 PM, Kelly O'Hair wrote:
> Looks fine, although I really hate all these $(QUIETLY) uses.
>
> Why would the "rm" in the clean rule not be quiet, but all these 
> critical build lines be quiet?
>
> The RE and others have a hard time tracking down build failures when 
> the rules are quiet,
> makes the build logs less than useful.
>
> -kto
>
> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>
>> I'm finally getting back to this thread. Since I'm also applying
>> Matthias' changes to the Solaris sa.makefile, I figured I would
>> send out a webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>
>> Kelly and Christian, can I get re-reviews from the two of you?
>>
>> Matthias, can you verify that I got the Solaris port of your
>> changes correct?
>>
>> Thanks, in advance, for any reviews...
>>
>> Dan
>>
>>
>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>
>>>>> Thanks for the reviews Kelly and Christian.
>>>>>
>>>>> Is there a reason to not apply these changes to the solaris and
>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>> would ask...
>>>>>
>>>>
>>>> Yeah, I also thought about this for Solaris and it should work 
>>>> there as
>>>> on Linux.  Don't know about Windows, though.
>>>>
>>>
>>> Looks like Windows already uses a "make" construct instead of running
>>> into the shell command line limitation:
>>>
>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>> <snip>
>>>
>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>> $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>> $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>
>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>> I think I'll look at applying the changes to the Solaris Makefile and
>>> leave the Windows stuff alone :-)
>>>
>>> Dan
>>>
>>>
>>>
>

From daniel.daugherty at oracle.com  Fri Sep  3 09:27:18 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Sep 2010 10:27:18 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <1283412159.16375.419.camel@macbook>
References: <4C736DDD.9040009@ubuntu.com>	
	<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>	
	<4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook>	
	<4C751B5C.4020500@oracle.com> <4C753E38.8070208@oracle.com>	
	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com>	 <4C7E93A3.1030401@oracle.com>	
	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
	<1283412159.16375.419.camel@macbook>
Message-ID: <4C8121E6.5000909@oracle.com>

On 9/2/2010 1:22 AM, Christian Thalinger wrote:
> On Wed, 2010-09-01 at 11:17 -0700, Tom Rodriguez wrote:
>   
>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?
>>     
>
> I agree.  The changes look good.  -- Christian
>   

Thanks for the re-review!

Dan


From daniel.daugherty at oracle.com  Fri Sep  3 09:29:04 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Sep 2010 10:29:04 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C7F5B1A.5000003@ubuntu.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>
	<4C7F5B1A.5000003@ubuntu.com>
Message-ID: <4C812250.2020406@oracle.com>

On 9/2/2010 2:06 AM, Matthias Klose wrote:
> On 01.09.2010 20:58, Kelly O'Hair wrote:
>> Looks fine, although I really hate all these $(QUIETLY) uses.
>>
>> Why would the "rm" in the clean rule not be quiet, but all these 
>> critical build
>> lines be quiet?
>
> I don't like quiet makes either, but I didn't want to change unrelated 
> things in the patch.

Agreed!


> If the $(QUIETLY) rm is needed for consistencey, fine with me.

I don't think the new 'rm' calls need $(QUIETLY).

Thanks for the review of the new part and thanks again for
the fix!

Dan


>
>> The RE and others have a hard time tracking down build failures when 
>> the rules
>> are quiet,
>> makes the build logs less than useful.
>>
>> -kto
>>
>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>
>>> I'm finally getting back to this thread. Since I'm also applying
>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>> send out a webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>
>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>
>>> Matthias, can you verify that I got the Solaris port of your
>>> changes correct?
>
> this looks ok to me.
>
>>> Thanks, in advance, for any reviews...
>>>
>>> Dan
>>>
>>>
>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>
>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>
>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>> would ask...
>>>>>>
>>>>>
>>>>> Yeah, I also thought about this for Solaris and it should work 
>>>>> there as
>>>>> on Linux. Don't know about Windows, though.
>>>>>
>>>>
>>>> Looks like Windows already uses a "make" construct instead of running
>>>> into the shell command line limitation:
>>>>
>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>> <snip>
>>>>
>>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>> $(SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>> $(SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>
>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>> leave the Windows stuff alone :-)
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>
>

From daniel.daugherty at oracle.com  Fri Sep  3 09:29:59 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Sep 2010 10:29:59 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <09109B10-9079-4A48-BB94-EED1724FC620@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<C8975B5A-638F-4C75-A9BE-0971EA6CE045@oracle.com>
	<4C7F5B1A.5000003@ubuntu.com>
	<09109B10-9079-4A48-BB94-EED1724FC620@oracle.com>
Message-ID: <4C812287.4010904@oracle.com>

On 9/2/2010 10:40 AM, Kelly O'Hair wrote:
>
> On Sep 2, 2010, at 1:06 AM, Matthias Klose wrote:
>
>> On 01.09.2010 20:58, Kelly O'Hair wrote:
>>> Looks fine, although I really hate all these $(QUIETLY) uses.
>>>
>>> Why would the "rm" in the clean rule not be quiet, but all these 
>>> critical build
>>> lines be quiet?
>>
>> I don't like quiet makes either, but I didn't want to change 
>> unrelated things in the patch. If the $(QUIETLY) rm is needed for 
>> consistencey, fine with me.
>
> It's ok, I'd rather leave it 'as is' than add more $(QUIETLY) uses.  I 
> was just making a point about
> quiet usage.  ;^)

Point made and understood!


>
> The changes looks fine.

Thanks! And thanks for the re-review!

Dan


>
> -kto
>
>>
>>> The RE and others have a hard time tracking down build failures when 
>>> the rules
>>> are quiet,
>>> makes the build logs less than useful.
>>>
>>> -kto
>>>
>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>
>>>> I'm finally getting back to this thread. Since I'm also applying
>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>> send out a webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>
>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>
>>>> Matthias, can you verify that I got the Solaris port of your
>>>> changes correct?
>>
>> this looks ok to me.
>>
>>>> Thanks, in advance, for any reviews...
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>
>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>
>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>> would ask...
>>>>>>>
>>>>>>
>>>>>> Yeah, I also thought about this for Solaris and it should work 
>>>>>> there as
>>>>>> on Linux. Don't know about Windows, though.
>>>>>>
>>>>>
>>>>> Looks like Windows already uses a "make" construct instead of running
>>>>> into the shell command line limitation:
>>>>>
>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>> <snip>
>>>>>
>>>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>> $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>> @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>> $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>
>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>>> leave the Windows stuff alone :-)
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>
>>
>

From daniel.daugherty at oracle.com  Fri Sep  3 17:12:27 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Sep 2010 18:12:27 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
Message-ID: <4C818EEB.7030107@oracle.com>

Here is the revised webrev:

http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/

One reviewer will do, I think...

Dan


On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>
> tom
>
> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>
>   
>> I'm finally getting back to this thread. Since I'm also applying
>> Matthias' changes to the Solaris sa.makefile, I figured I would
>> send out a webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>
>> Kelly and Christian, can I get re-reviews from the two of you?
>>
>> Matthias, can you verify that I got the Solaris port of your
>> changes correct?
>>
>> Thanks, in advance, for any reviews...
>>
>> Dan
>>
>>
>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>     
>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>       
>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>
>>>>         
>>>>> Thanks for the reviews Kelly and Christian.
>>>>>
>>>>> Is there a reason to not apply these changes to the solaris and
>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>> would ask...
>>>>>    
>>>>>           
>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>> on Linux.  Don't know about Windows, though.
>>>>  
>>>>         
>>> Looks like Windows already uses a "make" construct instead of running
>>> into the shell command line limitation:
>>>
>>>       
>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>         
>>> <snip>
>>>
>>>       
>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>         
>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>> I think I'll look at applying the changes to the Solaris Makefile and
>>> leave the Windows stuff alone :-)
>>>
>>> Dan
>>>
>>>
>>>
>>>       
>
>
>   

From tom.rodriguez at oracle.com  Fri Sep  3 17:21:53 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 3 Sep 2010 17:21:53 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C818EEB.7030107@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
	<4C818EEB.7030107@oracle.com>
Message-ID: <26C1C752-EA8F-48F6-A1FF-D85381C5120B@oracle.com>

Looks good.

tom

On Sep 3, 2010, at 5:12 PM, Daniel D. Daugherty wrote:

> Here is the revised webrev:
> 
> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
> 
> One reviewer will do, I think...
> 
> Dan
> 
> 
> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>> 
>> tom
>> 
>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>> 
>>  
>>> I'm finally getting back to this thread. Since I'm also applying
>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>> send out a webrev:
>>> 
>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>> 
>>> Kelly and Christian, can I get re-reviews from the two of you?
>>> 
>>> Matthias, can you verify that I got the Solaris port of your
>>> changes correct?
>>> 
>>> Thanks, in advance, for any reviews...
>>> 
>>> Dan
>>> 
>>> 
>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>    
>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>      
>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>> 
>>>>>        
>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>> 
>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>> would ask...
>>>>>>             
>>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>>> on Linux.  Don't know about Windows, though.
>>>>>         
>>>> Looks like Windows already uses a "make" construct instead of running
>>>> into the shell command line limitation:
>>>> 
>>>>      
>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>        
>>>> <snip>
>>>> 
>>>>      
>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>        
>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>> leave the Windows stuff alone :-)
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> 
>>>>      
>> 
>> 
>>  


From daniel.daugherty at oracle.com  Fri Sep  3 17:23:23 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Sep 2010 18:23:23 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <26C1C752-EA8F-48F6-A1FF-D85381C5120B@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>
	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>
	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>
	<4C75434B.7080307@oracle.com> <4C7E93A3.1030401@oracle.com>
	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
	<4C818EEB.7030107@oracle.com>
	<26C1C752-EA8F-48F6-A1FF-D85381C5120B@oracle.com>
Message-ID: <4C81917B.3000105@oracle.com>

Tom, thanks for the quick review!

With all the in-house JPRT chaos at the moment, I think I'll hold
off on submitting this job until later this weekend... when things
are hopefully quieter :-)

Dan


On 9/3/2010 6:21 PM, Tom Rodriguez wrote:
> Looks good.
>
> tom
>
> On Sep 3, 2010, at 5:12 PM, Daniel D. Daugherty wrote:
>
>   
>> Here is the revised webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>
>> One reviewer will do, I think...
>>
>> Dan
>>
>>
>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>     
>>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>>>
>>> tom
>>>
>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>
>>>  
>>>       
>>>> I'm finally getting back to this thread. Since I'm also applying
>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>> send out a webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>
>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>
>>>> Matthias, can you verify that I got the Solaris port of your
>>>> changes correct?
>>>>
>>>> Thanks, in advance, for any reviews...
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>    
>>>>         
>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>      
>>>>>           
>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>
>>>>>>        
>>>>>>             
>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>
>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>> would ask...
>>>>>>>             
>>>>>>>               
>>>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>         
>>>>>>             
>>>>> Looks like Windows already uses a "make" construct instead of running
>>>>> into the shell command line limitation:
>>>>>
>>>>>      
>>>>>           
>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>        
>>>>>>             
>>>>> <snip>
>>>>>
>>>>>      
>>>>>           
>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>        
>>>>>>             
>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>>> leave the Windows stuff alone :-)
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>  
>>>       
>
>   

From kanikchakravarty at gmail.com  Sun Sep  5 23:31:44 2010
From: kanikchakravarty at gmail.com (Kanik Chakravarty)
Date: Mon, 6 Sep 2010 07:31:44 +0100
Subject: Requesting urgent help for Final Project
Message-ID: <AANLkTimSYUZoptHzKyO8vKrwLKx0URsFVY+ErCLf5kMY@mail.gmail.com>

Hello
I am a complete newbie and very new to OpenJDk. I am trying to do a

project of simulating a cache in OpenJDk in Ubuntu. I have installed

OpenJDk in Ubunt. It is building. I have built the HotSpot projectin

NetBeans.
    I have a very silly problem and I did not ask it in this forum

for long  probably becaue its very lame. But here's my question:-
1. Is there a way to find out the addresses generated when a new

integer is declared or an array is declared? Is there a way of printing

addresses generated by the JVM to a local file?

2. How can I check that modifications to my local Hotspot project are

actually working. What are some of the basic test cases?

Any help would be highly appreciated.

Thanks and regards.
Kanik


-- 
Thanks and Regards,
Kanik Chakravarty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100906/c95913e2/attachment.html 

From Ulf.Zibis at gmx.de  Mon Sep  6 03:31:23 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 06 Sep 2010 12:31:23 +0200
Subject: Requesting urgent help for Final Project
In-Reply-To: <AANLkTimSYUZoptHzKyO8vKrwLKx0URsFVY+ErCLf5kMY@mail.gmail.com>
References: <AANLkTimSYUZoptHzKyO8vKrwLKx0URsFVY+ErCLf5kMY@mail.gmail.com>
Message-ID: <4C84C2FB.3030908@gmx.de>

  Maybe you could start here:
http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
http://kenai.com/projects/base-hsdis/downloads

-Ulf


Am 06.09.2010 08:31, schrieb Kanik Chakravarty:
> Hello
> I am a complete newbie and very new to OpenJDk. I am trying to do a
>
> project of simulating a cache in OpenJDk in Ubuntu. I have installed
>
> OpenJDk in Ubunt. It is building. I have built the HotSpot projectin
>
> NetBeans.
>     I have a very silly problem and I did not ask it in this forum
>
> for long  probably becaue its very lame. But here's my question:-
> 1. Is there a way to find out the addresses generated when a new
>
> integer is declared or an array is declared? Is there a way of printing
>
> addresses generated by the JVM to a local file?
>
> 2. How can I check that modifications to my local Hotspot project are
>
> actually working. What are some of the basic test cases?
>
> Any help would be highly appreciated.
>
> Thanks and regards.
> Kanik
>
>
> -- 
> Thanks and Regards,
> Kanik Chakravarty


From kanikchakravarty at gmail.com  Mon Sep  6 05:07:25 2010
From: kanikchakravarty at gmail.com (Kanik Chakravarty)
Date: Mon, 6 Sep 2010 13:07:25 +0100
Subject: Requesting urgent help for Final Project
In-Reply-To: <4C84C2FB.3030908@gmx.de>
References: <AANLkTimSYUZoptHzKyO8vKrwLKx0URsFVY+ErCLf5kMY@mail.gmail.com>
	<4C84C2FB.3030908@gmx.de>
Message-ID: <AANLkTikcwy61jBe6f6ubxN+Dj6hAKJgCtR7_FBaRb87t@mail.gmail.com>

Hi Ulf
Thanks for your prompt reply. I have not tried the disassembler yet but sure
looks helpful.

Thanks and regards
Kanik

On Mon, Sep 6, 2010 at 11:31 AM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

>  Maybe you could start here:
> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
> http://kenai.com/projects/base-hsdis/downloads
>
> -Ulf
>
>
> Am 06.09.2010 08:31, schrieb Kanik Chakravarty:
>
>  Hello
>> I am a complete newbie and very new to OpenJDk. I am trying to do a
>>
>> project of simulating a cache in OpenJDk in Ubuntu. I have installed
>>
>> OpenJDk in Ubunt. It is building. I have built the HotSpot projectin
>>
>> NetBeans.
>>    I have a very silly problem and I did not ask it in this forum
>>
>> for long  probably becaue its very lame. But here's my question:-
>> 1. Is there a way to find out the addresses generated when a new
>>
>> integer is declared or an array is declared? Is there a way of printing
>>
>> addresses generated by the JVM to a local file?
>>
>> 2. How can I check that modifications to my local Hotspot project are
>>
>> actually working. What are some of the basic test cases?
>>
>> Any help would be highly appreciated.
>>
>> Thanks and regards.
>> Kanik
>>
>>
>> --
>> Thanks and Regards,
>> Kanik Chakravarty
>>
>
>


-- 
Thanks and Regards,
Kanik Chakravarty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100906/9f530a9c/attachment.html 

From doko at ubuntu.com  Wed Sep  8 03:04:40 2010
From: doko at ubuntu.com (Matthias Klose)
Date: Wed, 08 Sep 2010 12:04:40 +0200
Subject: [patch, hotspot, sparc] fix compiler error with GCC 4.4 or newer
Message-ID: <4C875FB8.3080207@ubuntu.com>

the following patch is needed to fix a compiler error with GCC 4.4 or newer, 
required for openjdk7.

   Matthias

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sparc.diff
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100908/1c24d6c9/attachment.ksh 

From christian.thalinger at oracle.com  Wed Sep  8 03:23:36 2010
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 08 Sep 2010 12:23:36 +0200
Subject: [patch, hotspot, sparc] fix compiler error with GCC 4.4 or newer
In-Reply-To: <4C875FB8.3080207@ubuntu.com>
References: <4C875FB8.3080207@ubuntu.com>
Message-ID: <1283941416.24114.14.camel@macbook>

On Wed, 2010-09-08 at 12:04 +0200, Matthias Klose wrote:
> the following patch is needed to fix a compiler error with GCC 4.4 or newer, 
> required for openjdk7.

6983073: fix compiler error with GCC 4.4 or newer on SPARC

The changes look good and I'll push them for you.

-- Christian


From keith.mcguigan at oracle.com  Wed Sep  8 14:46:08 2010
From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com)
Date: Wed, 08 Sep 2010 21:46:08 +0000
Subject: hg: jdk7/hotspot/hotspot: 4 new changesets
Message-ID: <20100908214619.AF29D477F1@hg.openjdk.java.net>

Changeset: 6ee479178066
Author:    ikrylov
Date:      2010-08-31 03:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6ee479178066

6979444: add command line option to print command line flags descriptions
Summary: Implementation of a nonproduct boolean flag XX:PrintFlagsWithComments
Reviewed-by: kamg, dholmes, dsamersoff

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 1ab9e2cbfa0e
Author:    kamg
Date:      2010-09-03 14:47 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1ab9e2cbfa0e

6870851: Bad frame_chop in StackMapTable crashes JVM
Summary: Must check locals for null when processing chop frame
Reviewed-by: dholmes, dcubed

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

Changeset: 40d7b43b6fe0
Author:    kamg
Date:      2010-09-07 11:38 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/40d7b43b6fe0

Merge

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

Changeset: 07551f490c76
Author:    kamg
Date:      2010-09-07 11:50 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07551f490c76

6982851: Add b107 machine classifications to jprt.properties file.
Summary: See synopsis
Reviewed-by: ohair

! make/jprt.properties


From john.coomes at oracle.com  Wed Sep  8 15:29:11 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 08 Sep 2010 22:29:11 +0000
Subject: hg: jdk7/hotspot: 2 new changesets
Message-ID: <20100908222911.B986A477F5@hg.openjdk.java.net>

Changeset: 140fdef4ddf5
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/rev/140fdef4ddf5

Added tag jdk7-b107 for changeset 7d396ad455c3

! .hgtags

Changeset: 0df9c57eb80d
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/rev/0df9c57eb80d

Added tag jdk7-b108 for changeset 140fdef4ddf5

! .hgtags


From john.coomes at oracle.com  Wed Sep  8 15:29:18 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 08 Sep 2010 22:29:18 +0000
Subject: hg: jdk7/hotspot/corba: 2 new changesets
Message-ID: <20100908222920.65DEF477F6@hg.openjdk.java.net>

Changeset: 8d810527b499
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/8d810527b499

Added tag jdk7-b107 for changeset 232adb83eae8

! .hgtags

Changeset: 74d57b218468
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/74d57b218468

Added tag jdk7-b108 for changeset 8d810527b499

! .hgtags


From john.coomes at oracle.com  Wed Sep  8 15:30:10 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 08 Sep 2010 22:30:10 +0000
Subject: hg: jdk7/hotspot/jaxp: 2 new changesets
Message-ID: <20100908223010.4BC61477F7@hg.openjdk.java.net>

Changeset: 7d379f8934ca
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/7d379f8934ca

Added tag jdk7-b107 for changeset 20ee37c1372a

! .hgtags

Changeset: 840d6acde4e8
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/840d6acde4e8

Added tag jdk7-b108 for changeset 7d379f8934ca

! .hgtags


From john.coomes at oracle.com  Wed Sep  8 15:30:16 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 08 Sep 2010 22:30:16 +0000
Subject: hg: jdk7/hotspot/jaxws: 2 new changesets
Message-ID: <20100908223016.6EADE477F8@hg.openjdk.java.net>

Changeset: b1ca39340238
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/b1ca39340238

Added tag jdk7-b107 for changeset 017612ea6af4

! .hgtags

Changeset: ef7838f988c5
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/ef7838f988c5

Added tag jdk7-b108 for changeset b1ca39340238

! .hgtags


From john.coomes at oracle.com  Wed Sep  8 15:31:13 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 08 Sep 2010 22:31:13 +0000
Subject: hg: jdk7/hotspot/jdk: 43 new changesets
Message-ID: <20100908223846.2E4E1477F9@hg.openjdk.java.net>

Changeset: 17a5d84b7561
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/17a5d84b7561

Added tag jdk7-b107 for changeset 882103f334bb

! .hgtags

Changeset: d47bd9d94ba4
Author:    dlila
Date:      2010-08-10 13:19 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d47bd9d94ba4

6967436: lines longer than 2^15 can fill window.
6967433: dashed lines broken when using scaling transforms.
Summary: converted pisces to floating point. Also, using better AA algorithm
Reviewed-by: flar

! src/share/classes/sun/java2d/pisces/Dasher.java
! src/share/classes/sun/java2d/pisces/LineSink.java
- src/share/classes/sun/java2d/pisces/PiscesMath.java
! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
! src/share/classes/sun/java2d/pisces/Renderer.java
! src/share/classes/sun/java2d/pisces/Stroker.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: 4285edea9ddb
Author:    dlila
Date:      2010-08-11 10:05 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4285edea9ddb

6976265: No STROKE_CONTROL
Summary: implemented it in sun.java2d.pisces by adding a PathIterator.
Reviewed-by: flar

! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java

Changeset: 0576f6cc0463
Author:    lana
Date:      2010-08-12 19:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0576f6cc0463

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: 654145d6560a
Author:    lana
Date:      2010-08-23 19:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/654145d6560a

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: d0e314d59f84
Author:    malenkov
Date:      2010-08-10 19:29 +0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d0e314d59f84

6960267: JTable.getRowHeight() returns value different from the specified default (16.0) with GTK L&F
Reviewed-by: peterz

! src/share/classes/javax/swing/JTable.java

Changeset: 58626b4eedcb
Author:    lana
Date:      2010-08-12 11:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/58626b4eedcb

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: 23f72ec0d8e8
Author:    peytoia
Date:      2010-08-23 14:14 +0900
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/23f72ec0d8e8

6977550: (tz) Support tzdata2010l
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java

Changeset: a18a82d2d506
Author:    lana
Date:      2010-08-23 19:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a18a82d2d506

Merge


Changeset: 367b90ed38b1
Author:    chegar
Date:      2010-08-03 12:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/367b90ed38b1

6973030: NTLM proxy authentication fails with https
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java

Changeset: a21c46dac6cf
Author:    mullan
Date:      2010-08-03 09:39 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a21c46dac6cf

6653372: Error in java.security.KeyStore example code
Reviewed-by: weijun

! src/share/classes/java/security/KeyStore.java

Changeset: 2feeefb45a44
Author:    mullan
Date:      2010-08-03 09:55 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2feeefb45a44

Merge


Changeset: 3b63e506b57e
Author:    martin
Date:      2010-08-03 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3b63e506b57e

6955504: (str) String[Builder/Buffer].append(char[],int,int) throws OutOfMemoryError in b94
Summary: let arraycopy throw AIOOBE for invalid negative length
Reviewed-by: chegar, forax

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 188f156148ea
Author:    apangin
Date:      2010-08-04 20:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/188f156148ea

6945961: SIGSEGV in memcpy() during class loading on linux-i586
Summary: Check the result of strchr() in Bytecode Verifier
Reviewed-by: kamg, acorn

! src/share/native/common/check_code.c

Changeset: d47f5dcda481
Author:    dcubed
Date:      2010-08-06 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d47f5dcda481

6962604: 3/3 Testcase sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure
Summary: Disable MonitorVmStartTerminate.sh until 6543856 is fixed.
Reviewed-by: ohair

! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh

Changeset: 3e239fe92832
Author:    lancea
Date:      2010-08-10 10:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3e239fe92832

6898593: java.sql.Date.valueOf no exception if date given is not in the JDBC date escape syntax
Reviewed-by: minqi

! src/share/classes/java/sql/Date.java

Changeset: 1f996198877b
Author:    chegar
Date:      2010-08-10 17:30 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1f996198877b

6882910: Unexplained lack of IP4 network ability when transparent IP6 to IP4 is disabled.
Reviewed-by: alanb

! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/PlainSocketImpl.c
! src/solaris/native/sun/nio/ch/Net.c

Changeset: da5b67ac7755
Author:    sherman
Date:      2010-08-10 13:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/da5b67ac7755

6923794: About 40 JCK test case fail with AssertionError if -esa option is specified
Summary: removed the assert
Reviewed-by: alanb

! src/solaris/classes/java/io/UnixFileSystem.java
! src/windows/classes/java/io/Win32FileSystem.java

Changeset: 11ee8b471f9c
Author:    alanb
Date:      2010-08-12 19:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/11ee8b471f9c

6971825: (so) improve scatter/gather implementation
Reviewed-by: chegar, sherman

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/IOVecWrapper.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java

Changeset: 389bc53d0945
Author:    mchung
Date:      2010-08-12 16:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/389bc53d0945

6973831: NPE when printing stack trace of OOME
Summary: Initialize suppressedExceptions field to null
Reviewed-by: briangoetz, dholmes, forax

! src/share/classes/java/lang/Throwable.java

Changeset: cdd6d518f47e
Author:    mchung
Date:      2010-08-12 16:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cdd6d518f47e

Merge


Changeset: 041997c49f15
Author:    lana
Date:      2010-08-12 19:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/041997c49f15

Merge


Changeset: 0cdd73548292
Author:    gbenson
Date:      2010-08-13 22:26 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0cdd73548292

6976186: Integrate Shark
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: ohair

! make/jdk_generic_profile.sh

Changeset: 8329ebeabc10
Author:    mchung
Date:      2010-08-16 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8329ebeabc10

6921234: TEST_BUG: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be modified for Cygwin
Summary: Add check for CYGWIN
Reviewed-by: ohair

! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh

Changeset: 42eaa082a4e6
Author:    michaelm
Date:      2010-08-17 14:49 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/42eaa082a4e6

6339649: URI.create should include a detail message when throwing IllegalArgumentException
Summary: create enclosing exception with message of enclosed
Reviewed-by: alanb, chegar

! src/share/classes/java/net/URI.java
! test/java/net/URI/Test.java

Changeset: bfc3855a9341
Author:    sherman
Date:      2010-08-17 16:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bfc3855a9341

6969651: TEST_BUG: tools/jar/JarEntryTime.java failed on JDK7 when run on NFS
Summary: changed to use more appropriate nfs file time
Reviewed-by: martin

! test/tools/jar/JarEntryTime.java

Changeset: 01dec49e95c4
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/01dec49e95c4

6974005: Use of cygpath in Makefile logic needs to silence error messages
Reviewed-by: mchung

! make/common/shared/Defs-windows.gmk

Changeset: 42bfa43f2ae1
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/42bfa43f2ae1

6932743: Makefiles not parsing version strings with - from uname -r
Reviewed-by: mchung

! make/common/shared/Defs.gmk

Changeset: 4abd65f04638
Author:    weijun
Date:      2010-08-19 11:26 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4abd65f04638

6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default.
Reviewed-by: valeriep

! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
+ test/sun/security/krb5/BadKdcDefaultValue.java

Changeset: 95bb147c7c33
Author:    weijun
Date:      2010-08-19 12:24 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/95bb147c7c33

6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException
Reviewed-by: vinnie, xuelei

! src/share/classes/com/sun/jndi/ldap/Connection.java

Changeset: 1ce9c1690080
Author:    ksrini
Date:      2010-08-19 14:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1ce9c1690080

6888127: java.util.jar.Pack200.Packer Memory Leak
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Driver.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/Package.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
+ src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java

Changeset: 16e43f336262
Author:    ksrini
Date:      2010-08-20 08:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/16e43f336262

6966737: (pack200) the pack200 regression tests need to be more robust.
Reviewed-by: jrose, ohair

+ test/tools/pack200/CommandLineTests.java
- test/tools/pack200/Pack200Simple.sh
! test/tools/pack200/Pack200Test.java
! test/tools/pack200/PackageVersionTest.java
! test/tools/pack200/SegmentLimit.java
+ test/tools/pack200/Utils.java
+ test/tools/pack200/pack200-verifier/data/README
+ test/tools/pack200/pack200-verifier/data/golden.jar
+ test/tools/pack200/pack200-verifier/make/build.xml
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/ClassCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Globals.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/JarFileCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Main.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/VerifyTreeSet.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/CommandLineParser.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/TokenList.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/XMLKit.java

Changeset: db1b7c10de61
Author:    ksrini
Date:      2010-08-20 08:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/db1b7c10de61

Merge


Changeset: fd28003bc1d6
Author:    chegar
Date:      2010-08-23 14:35 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fd28003bc1d6

6968584: Thread should not be Cloneable
Reviewed-by: dholmes

! src/share/classes/java/lang/Thread.java

Changeset: 03218163f4d5
Author:    chegar
Date:      2010-08-23 16:27 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/03218163f4d5

6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe
Reviewed-by: michaelm

! src/share/classes/java/net/HttpCookie.java

Changeset: 47ab0dcec3e8
Author:    alanb
Date:      2010-08-23 17:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/47ab0dcec3e8

6978511: (file) Path.toRealPath should fail if not resolving links and file does not exist
Reviewed-by: forax, chegar

! src/solaris/classes/sun/nio/fs/UnixPath.java
! test/java/nio/file/Path/Misc.java

Changeset: f4a2b4e7a831
Author:    alanb
Date:      2010-08-23 17:35 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f4a2b4e7a831

6431344: (fc) FileChannel.transferTo() doesn't work if address space runs out
Reviewed-by: forax, chegar

! src/share/classes/sun/nio/ch/FileChannelImpl.java

Changeset: 6317f7e2c4fd
Author:    ksrini
Date:      2010-08-23 08:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6317f7e2c4fd

6531345: Memory leak in unpack200
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
+ test/tools/pack200/UnpackerMemoryTest.java
! test/tools/pack200/Utils.java

Changeset: cb67f0263bd4
Author:    chegar
Date:      2010-08-23 21:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cb67f0263bd4

6977851: NPE from FileURLConnection.connect
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.sh

Changeset: 2585368bfc7c
Author:    ksrini
Date:      2010-08-23 10:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2585368bfc7c

6969063: (pack200) The default value of Pack200.Packer.SEGMENT_LIMIT property is empty string instead of -1
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
+ test/tools/pack200/Pack200Props.java
- test/tools/pack200/SegmentLimit.java

Changeset: 732f59013e78
Author:    ksrini
Date:      2010-08-23 10:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/732f59013e78

6966740: (pack200) need to add the timezone regression test
Reviewed-by: jrose

+ test/tools/pack200/TimeStamp.java
! test/tools/pack200/Utils.java

Changeset: 62d37c19c213
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/62d37c19c213

Merge

- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 043d2736d44c
Author:    lana
Date:      2010-08-29 22:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/043d2736d44c

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java


From John.Coomes at oracle.com  Wed Sep  8 16:51:25 2010
From: John.Coomes at oracle.com (John Coomes)
Date: Wed, 8 Sep 2010 16:51:25 -0700
Subject: review request (XXS): 6983296: build sanity checks for jdk7
Message-ID: <19592.8573.108085.476627@oracle.com>

Trivial change to solaris makefiles to complain if anything other than
SS12u1 is used.  Prior to this change, SS12 was also accepted without
complaint.

http://cr.openjdk.java.net/~jcoomes/6983296-ss12u1-sanity/

-John


From kelly.ohair at oracle.com  Wed Sep  8 18:27:53 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 8 Sep 2010 18:27:53 -0700
Subject: review request (XXS): 6983296: build sanity checks for jdk7
In-Reply-To: <19592.8573.108085.476627@oracle.com>
References: <19592.8573.108085.476627@oracle.com>
Message-ID: <1084DD4A-EE5D-4218-9D0E-816616CC84E5@oracle.com>

Looks fine.

-kto

On Sep 8, 2010, at 4:51 PM, John Coomes wrote:

> Trivial change to solaris makefiles to complain if anything other than
> SS12u1 is used.  Prior to this change, SS12 was also accepted without
> complaint.
>
> http://cr.openjdk.java.net/~jcoomes/6983296-ss12u1-sanity/
>
> -John
>


From John.Coomes at oracle.com  Wed Sep  8 18:32:52 2010
From: John.Coomes at oracle.com (John Coomes)
Date: Wed, 8 Sep 2010 18:32:52 -0700
Subject: review request (XXS): 6983296: build sanity checks for jdk7
In-Reply-To: <1084DD4A-EE5D-4218-9D0E-816616CC84E5@oracle.com>
References: <19592.8573.108085.476627@oracle.com>
	<1084DD4A-EE5D-4218-9D0E-816616CC84E5@oracle.com>
Message-ID: <19592.14660.621656.3470@oracle.com>

Kelly O'Hair (kelly.ohair at oracle.com) wrote:
> Looks fine.

Many thanks.

-John

> On Sep 8, 2010, at 4:51 PM, John Coomes wrote:
> 
> > Trivial change to solaris makefiles to complain if anything other than
> > SS12u1 is used.  Prior to this change, SS12 was also accepted without
> > complaint.
> >
> > http://cr.openjdk.java.net/~jcoomes/6983296-ss12u1-sanity/
> >
> > -John
> >
> 


From erik.trimble at oracle.com  Wed Sep  8 18:34:04 2010
From: erik.trimble at oracle.com (erik.trimble at oracle.com)
Date: Thu, 09 Sep 2010 01:34:04 +0000
Subject: hg: jdk7/hotspot/hotspot: 5 new changesets
Message-ID: <20100909013413.979A04781C@hg.openjdk.java.net>

Changeset: e44a93947ccb
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e44a93947ccb

Added tag jdk7-b107 for changeset bf496cbe9b74

! .hgtags

Changeset: 6c43216df135
Author:    trims
Date:      2010-08-31 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c43216df135

Merge

! .hgtags

Changeset: 0803c0f69b51
Author:    trims
Date:      2010-08-31 17:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0803c0f69b51

Added tag hs19-b06 for changeset 6c43216df135

! .hgtags

Changeset: 40b1534a1dab
Author:    trims
Date:      2010-09-08 18:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/40b1534a1dab

Merge


Changeset: 93193e632121
Author:    trims
Date:      2010-09-08 18:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/93193e632121

6983320: Fork HS19 to HS20 - renumber Major and build numbers of JVM
Summary: Update the Major and Build numbers for HS20
Reviewed-by: jcoomes

! make/hotspot_version


From john.coomes at oracle.com  Wed Sep  8 18:51:54 2010
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 09 Sep 2010 01:51:54 +0000
Subject: hg: jdk7/hotspot/langtools: 18 new changesets
Message-ID: <20100909015231.622CE47823@hg.openjdk.java.net>

Changeset: a408ebb8b3d4
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a408ebb8b3d4

Added tag jdk7-b107 for changeset 2c1c657f69a4

! .hgtags

Changeset: 0fe472f4a332
Author:    mcimadamore
Date:      2010-08-05 09:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0fe472f4a332

6881115: javac permits nested anno w/o mandatory attrs => IncompleteAnnotationException
Summary: default annotation value is not attributed
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/6881115/T6881115.java
+ test/tools/javac/annotations/6881115/T6881115.out

Changeset: 237f3bd52242
Author:    mcimadamore
Date:      2010-08-05 09:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/237f3bd52242

6857948: Calling a constructor with a doubly bogus argument causes an internal error
Summary: problem when constructor resolution returns an erroneous symbol
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/6857948/T6857948.java
+ test/tools/javac/6857948/T6857948.out

Changeset: a2d8c7071f24
Author:    mcimadamore
Date:      2010-08-10 14:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a2d8c7071f24

6975275: diamond implementation needs some cleanup
Summary: resolution issues during diamond inference should be reported through Resolve.logResolveError()
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: ea1930f4b789
Author:    mcimadamore
Date:      2010-08-10 14:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ea1930f4b789

6975231: Regression test for 6881115 is failing with compiler output not matching expected output
Summary: missing symbols are collected in an HashSet which doesn't preserve ordering
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/annotations/6881115/T6881115.out
+ test/tools/javac/diags/examples/AnnotationMissingValues1.java

Changeset: c04ae2714f52
Author:    lana
Date:      2010-08-12 19:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c04ae2714f52

Merge


Changeset: 27bae58329d5
Author:    mcimadamore
Date:      2010-08-16 14:56 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/27bae58329d5

6976649: javac does not enforce required annotation elements in arrays
Summary: type annotation should take advantage of recursive annotation checking
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/annotations/6881115/T6881115.java
! test/tools/javac/annotations/6881115/T6881115.out
! test/tools/javac/annotations/pos/TrailingComma.java

Changeset: dc550520ed6f
Author:    mcimadamore
Date:      2010-08-16 14:58 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dc550520ed6f

6369605: Unconstrained type variables fails to include bounds
Summary: unconstrained type-variables with recursive bounds are not inferred properly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/InvalidInferredTypes.java
+ test/tools/javac/generics/inference/6369605/T6369605a.java
+ test/tools/javac/generics/inference/6369605/T6369605b.java
! test/tools/javac/generics/inference/6638712/T6638712a.out

Changeset: a31c511db424
Author:    jjg
Date:      2010-08-16 14:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a31c511db424

6976833: options included twice in Example SimpleCompiler
Reviewed-by: darcy

! test/tools/javac/diags/Example.java

Changeset: c655e0280bdc
Author:    mcimadamore
Date:      2010-08-19 11:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c655e0280bdc

6886247: regression: javac crashes with an assertion error in Attr.java
Summary: capture conversion does not work on nested types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_1.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.out

Changeset: d6fe0ea070aa
Author:    mcimadamore
Date:      2010-08-19 11:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d6fe0ea070aa

6885255: Improve usability of raw warnings
Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/warnings/6747671/T6747671.java
! test/tools/javac/warnings/6747671/T6747671.out
+ test/tools/javac/warnings/6885255/T6885255.java
+ test/tools/javac/warnings/6885255/T6885255.out

Changeset: a75770c0d7f6
Author:    mcimadamore
Date:      2010-08-19 11:54 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a75770c0d7f6

6977800: Regression: invalid resolution of supertype for local class
Summary: resolution of superclass/superinterfaces in extends/implements clause skips local classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/T6977800.java
! test/tools/javac/generics/typevars/5060485/Compatibility.java
+ test/tools/javac/generics/typevars/5060485/Compatibility.out
+ test/tools/javac/generics/typevars/5060485/Compatibility02.java
+ test/tools/javac/generics/typevars/5060485/Compatibility02.out

Changeset: 995bcdb9a41d
Author:    mcimadamore
Date:      2010-08-23 16:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/995bcdb9a41d

6932571: Compiling Generics causing Inconvertible types
Summary: Types.rewriteQuantifiers() does not work well with recursive type-variable bounds
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6270087/T6270087.java
+ test/tools/javac/cast/6270087/T6270087neg.java
+ test/tools/javac/cast/6270087/T6270087neg.out
+ test/tools/javac/cast/6507317/T6507317.java
+ test/tools/javac/cast/6569057/T6569057.java
+ test/tools/javac/cast/6932571/T6932571a.java
+ test/tools/javac/cast/6932571/T6932571b.java
+ test/tools/javac/cast/6932571/T6932571neg.java
+ test/tools/javac/cast/6932571/T6932571neg.out

Changeset: 594b3c2ef585
Author:    mcimadamore
Date:      2010-08-23 17:00 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/594b3c2ef585

6978574: return statement in try block with multi-catch causes ClassFormatError
Summary: Wrong nested loops in Gen.java causes javac to generate bad bytecode
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/multicatch/T6978574.java

Changeset: 6b95dd682538
Author:    jjg
Date:      2010-08-23 11:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6b95dd682538

6975005: improve JavacProcessingEnvironment.Round abstraction
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/T6358024.java
! test/tools/javac/T6403466.out
! test/tools/javac/processing/filer/TestLastRound.out

Changeset: a626d8c1de6e
Author:    jjg
Date:      2010-08-23 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a626d8c1de6e

6976747: JCDiagnostic: replace "boolean mandatory" with new "Set<JCDiagnostic.Flag>"
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java

Changeset: 0c81bff15ced
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0c81bff15ced

Merge


Changeset: ba774f919ad0
Author:    lana
Date:      2010-08-29 22:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ba774f919ad0

Merge



From doug.simon at oracle.com  Thu Sep  9 02:16:17 2010
From: doug.simon at oracle.com (Douglas Simon)
Date: Thu, 9 Sep 2010 11:16:17 +0200
Subject: C++ exceptions in HotSpot source code
Message-ID: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>

Hi,

Just out of curiousity, why (apart from good taste!) are C++ exceptions not used in HotSpot source code? Is it problems with the semantics of C++ exceptions or something to do with problematic implementations of exceptions by various C++ compilers or a combination of the two?

-Doug

From dmdabbs at gmail.com  Thu Sep  9 12:04:45 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Thu, 9 Sep 2010 14:04:45 -0500
Subject: jdk and NUMA
Message-ID: <003301cb5051$f5e99490$e1bcbdb0$@com>


My apologies if this is not the correct place for this question.

I have a shiny new NUMA-capable Xeon server and want to ensure that my Java
app(s) make full use of the hardware.
So, I ran java (jdk 6u21) -XX:+PrintFlagsFinal and (naively) expected to see
UseNUMA := true but did not.

I found this post

http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary

If its simply a matter of turning it on that's what I'll do. Any guidelines
about use of mumactl or the jdks NUMA "knobs"?


uname -a
Linux 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64
x86_64 GNU/Linux

Linux, CentOS 5


cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz
stepping        : 5
cpu MHz         : 2394.112
cache size      : 8192 KB
physical id     : 1
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 16
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp
lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr
popcnt lahf_lm
bogomips        : 4791.64
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: [8]        

This repeats for processors 1-15.

Two physical ids, 0,1.




From tom.rodriguez at oracle.com  Thu Sep  9 13:02:41 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 9 Sep 2010 13:02:41 -0700
Subject: C++ exceptions in HotSpot source code
In-Reply-To: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>
References: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>
Message-ID: <35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>

I think it's primarily history.  At the point hotspot was being written neither generic nor exceptions were mature or widely in use.  We'd also chosen to use a small core of C++ in the interests of avoiding portability problems caused by the variability of C++ implementations.

tom

On Sep 9, 2010, at 2:16 AM, Douglas Simon wrote:

> Hi,
> 
> Just out of curiousity, why (apart from good taste!) are C++ exceptions not used in HotSpot source code? Is it problems with the semantics of C++ exceptions or something to do with problematic implementations of exceptions by various C++ compilers or a combination of the two?
> 
> -Doug


From paul.hohensee at oracle.com  Thu Sep  9 13:24:09 2010
From: paul.hohensee at oracle.com (Paul Hohensee)
Date: Thu, 09 Sep 2010 16:24:09 -0400
Subject: C++ exceptions in HotSpot source code
In-Reply-To: <35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>
References: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>
	<35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>
Message-ID: <4C894269.50905@oracle.com>

  Tom's right about portability.  C++ exception handling can interfere 
with Hotspot's
exception handling mechanisms.  How the former is implemented varies
from compiler to compiler, so even if we had workarounds, we'd still
have to write one workaround per compiler, and we don't want to track
C++ compiler implementations any more than we already do.

Paul

On 9/9/10 4:02 PM, Tom Rodriguez wrote:
> I think it's primarily history.  At the point hotspot was being written neither generic nor exceptions were mature or widely in use.  We'd also chosen to use a small core of C++ in the interests of avoiding portability problems caused by the variability of C++ implementations.
>
> tom
>
> On Sep 9, 2010, at 2:16 AM, Douglas Simon wrote:
>
>> Hi,
>>
>> Just out of curiousity, why (apart from good taste!) are C++ exceptions not used in HotSpot source code? Is it problems with the semantics of C++ exceptions or something to do with problematic implementations of exceptions by various C++ compilers or a combination of the two?
>>
>> -Doug

From dmdabbs at gmail.com  Thu Sep  9 15:44:48 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Thu, 9 Sep 2010 17:44:48 -0500
Subject: jdk and NUMA
In-Reply-To: <4C896021.8010708@oracle.com>
References: <003301cb5051$f5e99490$e1bcbdb0$@com> <4C896021.8010708@oracle.com>
Message-ID: <003301cb5070$9d4efdb0$d7ecf910$@com>

Thank you ramki, for the reply.

What "issues" should might one expect after adding +UseNUMA?




-----Original Message-----
From: Y. S. Ramakrishna [mailto: @oracle.com] 
Sent: Thursday, September 09, 2010 5:31 PM
To: David Dabbs
Subject: Re: jdk and NUMA

Yes, just use +UseNUMA to begin with, and let us know if there are
any issues.

-- ramki

On 09/09/10 12:04, David Dabbs wrote:
> My apologies if this is not the correct place for this question.
> 
> I have a shiny new NUMA-capable Xeon server and want to ensure that my
Java
> app(s) make full use of the hardware.
> So, I ran java (jdk 6u21) -XX:+PrintFlagsFinal and (naively) expected to
see
> UseNUMA := true but did not.
> 
> I found this post
> 
> http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary
> 
> If its simply a matter of turning it on that's what I'll do. Any
guidelines
> about use of mumactl or the jdks NUMA "knobs"?
> 
> 
> uname -a
> Linux 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64
> x86_64 GNU/Linux
> 
> Linux, CentOS 5
> 
> 
> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 26
> model name      : Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz
> stepping        : 5
> cpu MHz         : 2394.112
> cache size      : 8192 KB
> physical id     : 1
> siblings        : 8
> core id         : 0
> cpu cores       : 4
> apicid          : 16
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx
rdtscp
> lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr
> popcnt lahf_lm
> bogomips        : 4791.64
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management: [8]        
> 
> This repeats for processors 1-15.
> 
> Two physical ids, 0,1.
> 
> 
> 

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.851 / Virus Database: 271.1.1/3124 - Release Date: 09/09/10
01:34:00


From charlie.hunt at sun.com  Thu Sep  9 16:33:47 2010
From: charlie.hunt at sun.com (Charlie Hunt)
Date: Thu, 09 Sep 2010 18:33:47 -0500
Subject: jdk and NUMA
Message-ID: <puth6t1f6pvl8jnh3in87s79.1284075227979@email.android.com>

In general, best practice .... use +UseNUMA when the jvm you are launching will span more than one memory node.

Charlie 

David Dabbs <dmdabbs at gmail.com> wrote:

>Thank you ramki, for the reply.
>
>What "issues" should might one expect after adding +UseNUMA?
>
>
>
>
>-----Original Message-----
>From: Y. S. Ramakrishna [mailto: @oracle.com] 
>Sent: Thursday, September 09, 2010 5:31 PM
>To: David Dabbs
>Subject: Re: jdk and NUMA
>
>Yes, just use +UseNUMA to begin with, and let us know if there are
>any issues.
>
>-- ramki
>
>On 09/09/10 12:04, David Dabbs wrote:
>> My apologies if this is not the correct place for this question.
>> 
>> I have a shiny new NUMA-capable Xeon server and want to ensure that my
>Java
>> app(s) make full use of the hardware.
>> So, I ran java (jdk 6u21) -XX:+PrintFlagsFinal and (naively) expected to
>see
>> UseNUMA := true but did not.
>> 
>> I found this post
>> 
>> http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary
>> 
>> If its simply a matter of turning it on that's what I'll do. Any
>guidelines
>> about use of mumactl or the jdks NUMA "knobs"?
>> 
>> 
>> uname -a
>> Linux 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64
>> x86_64 GNU/Linux
>> 
>> Linux, CentOS 5
>> 
>> 
>> cat /proc/cpuinfo
>> 
>> processor       : 0
>> vendor_id       : GenuineIntel
>> cpu family      : 6
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz
>> stepping        : 5
>> cpu MHz         : 2394.112
>> cache size      : 8192 KB
>> physical id     : 1
>> siblings        : 8
>> core id         : 0
>> cpu cores       : 4
>> apicid          : 16
>> fpu             : yes
>> fpu_exception   : yes
>> cpuid level     : 11
>> wp              : yes
>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx
>rdtscp
>> lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr
>> popcnt lahf_lm
>> bogomips        : 4791.64
>> clflush size    : 64
>> cache_alignment : 64
>> address sizes   : 40 bits physical, 48 bits virtual
>> power management: [8]        
>> 
>> This repeats for processors 1-15.
>> 
>> Two physical ids, 0,1.
>> 
>> 
>> 
>
>No virus found in this incoming message.
>Checked by AVG - www.avg.com 
>Version: 9.0.851 / Virus Database: 271.1.1/3124 - Release Date: 09/09/10
>01:34:00
>

From dmdabbs at gmail.com  Thu Sep  9 16:55:53 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Thu, 9 Sep 2010 18:55:53 -0500
Subject: jdk and NUMA
In-Reply-To: <puth6t1f6pvl8jnh3in87s79.1284075227979@email.android.com>
References: <puth6t1f6pvl8jnh3in87s79.1284075227979@email.android.com>
Message-ID: <003f01cb507a$8a3eba30$9ebc2e90$@com>

>Charlie Hunt
>In general, best practice 
>use +UseNUMA when the jvm you are launching will span more than one memory node.

Hi Charlie.

Apologies for my ignorance, but how would I know that this is the case? 
We're running a servlet container (Tomcat) with no special CPU affinities or numactl.
So I'm guessing that this qualifies as spanning more than one memory node.

Thanks!

David



-----Original Message-----
From: [mailto:charlie.hunt at sun.com] 
Sent: Thursday, September 09, 2010 6:34 PM
To: David Dabbs; hotspot-dev at openjdk.java.net
Subject: RE: jdk and NUMA

In general, best practice .... use +UseNUMA when the jvm you are launching will span more than one memory node.

Charlie 

David Dabbs <dmdabbs at gmail.com> wrote:

>Thank you ramki, for the reply.
>
>What "issues" should might one expect after adding +UseNUMA?
>
>
>
>
>-----Original Message-----
>From: Y. S. Ramakrishna [mailto: @oracle.com] 
>Sent: Thursday, September 09, 2010 5:31 PM
>To: David Dabbs
>Subject: Re: jdk and NUMA
>
>Yes, just use +UseNUMA to begin with, and let us know if there are
>any issues.
>
>-- ramki
>
>On 09/09/10 12:04, David Dabbs wrote:
>> My apologies if this is not the correct place for this question.
>> 
>> I have a shiny new NUMA-capable Xeon server and want to ensure that my
>Java
>> app(s) make full use of the hardware.
>> So, I ran java (jdk 6u21) -XX:+PrintFlagsFinal and (naively) expected to
>see
>> UseNUMA := true but did not.
>> 
>> I found this post
>> 
>> http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary
>> 
>> If its simply a matter of turning it on that's what I'll do. Any
>guidelines
>> about use of mumactl or the jdks NUMA "knobs"?
>> 
>> 
>> uname -a
>> Linux 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64
>> x86_64 GNU/Linux
>> 
>> Linux, CentOS 5
>> 
>> 
>> cat /proc/cpuinfo
>> 
>> processor       : 0
>> vendor_id       : GenuineIntel
>> cpu family      : 6
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz
>> stepping        : 5
>> cpu MHz         : 2394.112
>> cache size      : 8192 KB
>> physical id     : 1
>> siblings        : 8
>> core id         : 0
>> cpu cores       : 4
>> apicid          : 16
>> fpu             : yes
>> fpu_exception   : yes
>> cpuid level     : 11
>> wp              : yes
>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx
>rdtscp
>> lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr
>> popcnt lahf_lm
>> bogomips        : 4791.64
>> clflush size    : 64
>> cache_alignment : 64
>> address sizes   : 40 bits physical, 48 bits virtual
>> power management: [8]        
>> 
>> This repeats for processors 1-15.
>> 
>> Two physical ids, 0,1.
>> 
>> 
>> 
>
>No virus found in this incoming message.
>Checked by AVG - www.avg.com 
>Version: 9.0.851 / Virus Database: 271.1.1/3124 - Release Date: 09/09/10
>01:34:00
>

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.851 / Virus Database: 271.1.1/3124 - Release Date: 09/09/10 13:34:00


From dmdabbs at gmail.com  Thu Sep  9 19:10:18 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Thu, 9 Sep 2010 21:10:18 -0500
Subject: Is WorkAroundNPTLTimedWaitHang safe to disable?
In-Reply-To: <35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>
References: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>
	<35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>
Message-ID: <000001cb508d$59a864d0$0cf92e70$@com>

Hello.

There is a Linux-specific VM product flag, WorkAroundNPTLTimedWaitHang.
The comments in src/share/vm/runtime/globals.hpp describe the flag as 

	(Unstable, Linux-specific) "avoid NPTL-FUTEX hang
pthread_cond_timedwait"

Would this be a workaround for this issue?  

	https://bugzilla.redhat.com/show_bug.cgi?id=217067


In any case, are there are guidelines for safely disabling this workaround?
Guidelines, e.g. libc version, vendor.kernel.version, et cetera.


Many thanks,

David



From David.Holmes at oracle.com  Thu Sep  9 19:39:03 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 10 Sep 2010 12:39:03 +1000
Subject: Is WorkAroundNPTLTimedWaitHang safe to disable?
In-Reply-To: <000001cb508d$59a864d0$0cf92e70$@com>
References: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>	<35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>
	<000001cb508d$59a864d0$0cf92e70$@com>
Message-ID: <4C899A47.80506@oracle.com>

David Dabbs said the following on 09/10/10 12:10:
> There is a Linux-specific VM product flag, WorkAroundNPTLTimedWaitHang.
> The comments in src/share/vm/runtime/globals.hpp describe the flag as 
> 
> 	(Unstable, Linux-specific) "avoid NPTL-FUTEX hang
> pthread_cond_timedwait"
> 
> Would this be a workaround for this issue?  
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=217067

No it predates that issue by several years. See the comments in 
os_linux.cpp:

// Beware -- Some versions of NPTL embody a flaw where 
pthread_cond_timedwait() can
// hang indefinitely.  For instance NPTL 0.60 on 2.4.21-4ELsmp is 
vulnerable.
// For specifics regarding the bug see GLIBC BUGID 261237 :
// 
http://www.mail-archive.com/debian-glibc at lists.debian.org/msg10837.html.
// Briefly, pthread_cond_timedwait() calls with an expiry time that's 
not in the future
// will either hang or corrupt the condvar, resulting in subsequent 
hangs if the condvar
// is used.  (The simple C test-case provided in the GLIBC bug report 
manifests the
// hang).  The JVM is vulernable via sleep(), Object.wait(timo), 
LockSupport.parkNanos()
// and monitorenter when we're using 1-0 locking.  All those operations 
may result in
// calls to pthread_cond_timedwait().  Using LD_ASSUME_KERNEL to use an 
older version
// of libpthread avoids the problem, but isn't practical.

> In any case, are there are guidelines for safely disabling this workaround?
> Guidelines, e.g. libc version, vendor.kernel.version, et cetera.

We have not tracked this. Given the widespread Linux/glibc versions 
people use, these workarounds tend to have to stay around a long time. A 
lot of code cleanups would be possible if we enforced a minimum 
kerbel+glibc version.

David Holmes




> 
> Many thanks,
> 
> David
> 
> 

From dmdabbs at gmail.com  Fri Sep 10 02:24:15 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Fri, 10 Sep 2010 04:24:15 -0500
Subject: guarantee(!UseCompressedStrings) failed: missed java implementation
	of Compressed Strings
In-Reply-To: <4C899A47.80506@oracle.com>
References: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>	<35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>
	<000001cb508d$59a864d0$0cf92e70$@com> <4C899A47.80506@oracle.com>
Message-ID: <003901cb50c9$f20bcfa0$d6236ee0$@com>


When I attempted to use UseCompressedStrings with 7 b109, java crashed with
the following message. 
I have filed a bug report.


Cheers,

David


-XX:+AggressiveOpts -XX:-BytecodeVerificationLocal
-XX:-BytecodeVerificationRemote -XX:InitialHeapSize=134217728 -XX:Max
HeapSize=536870912 -XX:MaxNewSize=43622400 -XX:MaxPermSize=262144000
-XX:MaxTenuringThreshold=4 -XX:NewRatio=7 -XX:NewSi
ze=21811200 -XX:OldPLABSize=16 -XX:OldSize=65433600
-XX:+OptimizeStringConcat -XX:+PrintCommandLineFlags -XX:+PrintFlags
Final -XX:+UnlockExperimentalVMOptions -XX:+UseCodeCacheFlushing
-XX:+UseCompressedOops -XX:+UseCompressedStrings -XX:+U
seConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (javaClasses.cpp:2962), pid=4232, tid=4196
#  guarantee(!UseCompressedStrings) failed: missed java implementation of
Compressed Strings
#
# JRE version: 7.0
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b06 mixed mode
windows-amd64 compressed oops)
# An error report file with more information is saved as:
# C:\Users\davidd\AppData\Local\Temp\\hs_err_pid4232.log
#


FWIW, here are the VM args from the command line:

-server
-ea
-Djava.net.preferIPv4Stack=true
-Xverify:none
-Xms128m
-Xmx512m
-XX:MaxPermSize=250m
-XX:+UnlockExperimentalVMOptions
-XX:+AggressiveOpts
-XX:+UseCompressedStrings
-XX:+UseConcMarkSweepGC
-XX:+OptimizeStringConcat
-XX:+UseCodeCacheFlushing
-XX:+PrintCommandLineFlags
-XX:+PrintFlagsFinal



From David.Holmes at oracle.com  Fri Sep 10 02:45:23 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 10 Sep 2010 19:45:23 +1000
Subject: guarantee(!UseCompressedStrings) failed: missed java
	implementation of Compressed Strings
In-Reply-To: <003901cb50c9$f20bcfa0$d6236ee0$@com>
References: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>	<35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>	<000001cb508d$59a864d0$0cf92e70$@com>
	<4C899A47.80506@oracle.com> <003901cb50c9$f20bcfa0$d6236ee0$@com>
Message-ID: <4C89FE33.5070105@oracle.com>

David Dabbs said the following on 09/10/10 19:24:
> When I attempted to use UseCompressedStrings with 7 b109, java crashed with
> the following message. 
> I have filed a bug report.

It's a known issue. I don't think UseCompressedStrings is ready for use yet.

David Holmes

> 
> Cheers,
> 
> David
> 
> 
> -XX:+AggressiveOpts -XX:-BytecodeVerificationLocal
> -XX:-BytecodeVerificationRemote -XX:InitialHeapSize=134217728 -XX:Max
> HeapSize=536870912 -XX:MaxNewSize=43622400 -XX:MaxPermSize=262144000
> -XX:MaxTenuringThreshold=4 -XX:NewRatio=7 -XX:NewSi
> ze=21811200 -XX:OldPLABSize=16 -XX:OldSize=65433600
> -XX:+OptimizeStringConcat -XX:+PrintCommandLineFlags -XX:+PrintFlags
> Final -XX:+UnlockExperimentalVMOptions -XX:+UseCodeCacheFlushing
> -XX:+UseCompressedOops -XX:+UseCompressedStrings -XX:+U
> seConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (javaClasses.cpp:2962), pid=4232, tid=4196
> #  guarantee(!UseCompressedStrings) failed: missed java implementation of
> Compressed Strings
> #
> # JRE version: 7.0
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b06 mixed mode
> windows-amd64 compressed oops)
> # An error report file with more information is saved as:
> # C:\Users\davidd\AppData\Local\Temp\\hs_err_pid4232.log
> #
> 
> 
> FWIW, here are the VM args from the command line:
> 
> -server
> -ea
> -Djava.net.preferIPv4Stack=true
> -Xverify:none
> -Xms128m
> -Xmx512m
> -XX:MaxPermSize=250m
> -XX:+UnlockExperimentalVMOptions
> -XX:+AggressiveOpts
> -XX:+UseCompressedStrings
> -XX:+UseConcMarkSweepGC
> -XX:+OptimizeStringConcat
> -XX:+UseCodeCacheFlushing
> -XX:+PrintCommandLineFlags
> -XX:+PrintFlagsFinal
> 
> 

From vladimir.kozlov at oracle.com  Fri Sep 10 10:08:23 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 10 Sep 2010 10:08:23 -0700
Subject: guarantee(!UseCompressedStrings) failed: missed java
	implementation of Compressed Strings
In-Reply-To: <4C89FE33.5070105@oracle.com>
References: <C0A14E5B-53DE-4F90-A21E-270680EF8DAB@oracle.com>	<35746105-9FC2-473F-91BE-44113E7CBA6C@oracle.com>	<000001cb508d$59a864d0$0cf92e70$@com>	<4C899A47.80506@oracle.com>
	<003901cb50c9$f20bcfa0$d6236ee0$@com> <4C89FE33.5070105@oracle.com>
Message-ID: <4C8A6607.10405@oracle.com>

Currently Compressed Strings are not supported in jdk 7 and I can't say when it will be.

Vladimir

David Holmes wrote:
> David Dabbs said the following on 09/10/10 19:24:
>> When I attempted to use UseCompressedStrings with 7 b109, java crashed 
>> with
>> the following message. I have filed a bug report.
> 
> It's a known issue. I don't think UseCompressedStrings is ready for use 
> yet.
> 
> David Holmes
> 
>>
>> Cheers,
>>
>> David
>>
>>
>> -XX:+AggressiveOpts -XX:-BytecodeVerificationLocal
>> -XX:-BytecodeVerificationRemote -XX:InitialHeapSize=134217728 -XX:Max
>> HeapSize=536870912 -XX:MaxNewSize=43622400 -XX:MaxPermSize=262144000
>> -XX:MaxTenuringThreshold=4 -XX:NewRatio=7 -XX:NewSi
>> ze=21811200 -XX:OldPLABSize=16 -XX:OldSize=65433600
>> -XX:+OptimizeStringConcat -XX:+PrintCommandLineFlags -XX:+PrintFlags
>> Final -XX:+UnlockExperimentalVMOptions -XX:+UseCodeCacheFlushing
>> -XX:+UseCompressedOops -XX:+UseCompressedStrings -XX:+U
>> seConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (javaClasses.cpp:2962), pid=4232, tid=4196
>> #  guarantee(!UseCompressedStrings) failed: missed java implementation of
>> Compressed Strings
>> #
>> # JRE version: 7.0
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b06 mixed mode
>> windows-amd64 compressed oops)
>> # An error report file with more information is saved as:
>> # C:\Users\davidd\AppData\Local\Temp\\hs_err_pid4232.log
>> #
>>
>>
>> FWIW, here are the VM args from the command line:
>>
>> -server
>> -ea
>> -Djava.net.preferIPv4Stack=true
>> -Xverify:none
>> -Xms128m
>> -Xmx512m
>> -XX:MaxPermSize=250m
>> -XX:+UnlockExperimentalVMOptions
>> -XX:+AggressiveOpts
>> -XX:+UseCompressedStrings
>> -XX:+UseConcMarkSweepGC
>> -XX:+OptimizeStringConcat
>> -XX:+UseCodeCacheFlushing
>> -XX:+PrintCommandLineFlags
>> -XX:+PrintFlagsFinal
>>
>>

From dmdabbs at gmail.com  Sun Sep 12 00:45:24 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Sun, 12 Sep 2010 02:45:24 -0500
Subject: InitialCodeCacheSize sizing. . .
In-Reply-To: <4C89E22E.1020006@oracle.com>
References: <puth6t1f6pvl8jnh3in87s79.1284075227979@email.android.com>
	<003f01cb507a$8a3eba30$9ebc2e90$@com> <4C89E22E.1020006@oracle.com>
Message-ID: <001201cb524e$779807d0$66c81770$@com>

In comments in c2_globals_x86.hpp indicate that 

  // InitialCodeCacheSize [was] derived from specjbb2000 run.

and the flag value is set to

  // Integral multiple of CodeCacheExpansionSize 
  define_pd_global(intx, InitialCodeCacheSize,   2496*K);
  define_pd_global(intx, CodeCacheExpansionSize, 64*K);


As of January 2006, according to the spec.org website, 

   "SPECjbb2000 has been retired and replaced by SPECjbb2005,
    results submissions are no longer being accepted and 
    support is no longer provided." 


Would the InitialCodeCacheSize default setting have changed significantly in the 
(presumably) four-five years since SPECjbb2000 was used to size the CodeCache initial size?

Or, put another way, what impact on performance would an undersized CodeCache have?
Do you think there are other system or product_pd defaults that might be "dusty"?

FWIW, here are the spec.org blurbs regarding Java-related benchmarks. See http://www.spec.org/benchmarks.html#java.


# SPECjAppServer2004
SPECjAppServer2004 is designed to measure the performance of J2EE 1.3 application servers. 
Includes an enhanced workload by adding a web tier, JMS, and other changes to SPECjAppServer2002.

# SPECjEnterprise2010
Measures performance for Java EE 5 or later application servers, databases and supporting infrastructure.
It expands the scope of the SPECjAppServer2004 benchmark.

# SPECjbb2005
Evaluates the performance of servers running typical Java business applications. 
JBB2005 represents an order processing application for a wholesale supplier. 
Can be used to evaluate performance of hardware and software aspects of Java Virtual Machine (JVM) servers.

# SPECjvm2008
SPECjvm2008 is a benchmark suite for measuring performance of a Java Runtime Environment (JRE).
It contains several real life applications and benchmarks focusing on core java functionality. 
The SPECjvm2008 workload mimics a variety of common general purpose application computations.


If one were to re-evaluate the setting, seems like SPECjEnterprise2010 would be the one to use.


Cheers,

David




From dmdabbs at gmail.com  Sun Sep 12 04:24:44 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Sun, 12 Sep 2010 06:24:44 -0500
Subject: What performance impact should one expect when setting
	UsePerfData=false?
Message-ID: <001b01cb526d$1a827020$4f875060$@com>

Hello.

What performance impact (improvement) should one expect when setting
UsePerfData=false?


Also, I noticed that PerfDataSaveFile silently overrides PerfDataSaveToFile.

While anyone using this probably knows what they're doing, should
PrintFlagsFinal make this explicit? 


  /* performance data collection */

  product(bool, UsePerfData, true,            
          "Flag to disable jvmstat instrumentation for performance testing"
          "and problem isolation purposes.")  
                                              
  product(bool, PerfDataSaveToFile, false,    
          "Save PerfData memory to hsperfdata_<pid> file on exit")    
                                              
  product(ccstr, PerfDataSaveFile, NULL,      
          "Save PerfData memory to the specified absolute pathname,"  
           "%p in the file name if present will be replaced by pid")  

  // NOTE: If user specifies PerfDataSaveFile, it will save the performance
data
  // to the specified file name no matter whether PerfDataSaveToFile is
specified
  // or not. In other word, -XX:PerfDataSaveFile=.. overrides flag
  // -XX:+PerfDataSaveToFile.

   
  product(intx, PerfDataSamplingInterval, 50 /*ms*/,     
          "Data sampling interval in milliseconds")      
                                              
  product(bool, PerfDisableSharedMem, false,  
          "Store performance data in standard memory")   
                                              
  product(intx, PerfDataMemorySize, 32*K,     
          "Size of performance data memory region. Will be rounded "  
          "up to a multiple of the native os page size.")
                                              
  product(intx, PerfMaxStringConstLength, 1024,          
          "Maximum PerfStringConstant string length before truncation")
                                              
  product(bool, PerfAllowAtExitRegistration, false,      
          "Allow registration of atexit() methods")      
                                              
  product(bool, PerfBypassFileSystemCheck, false,        
          "Bypass Win32 file system criteria checks (Windows Only)")  






From charlie.hunt at oracle.com  Thu Sep  9 19:05:15 2010
From: charlie.hunt at oracle.com (charlie hunt)
Date: Thu, 09 Sep 2010 21:05:15 -0500
Subject: jdk and NUMA
In-Reply-To: <003f01cb507a$8a3eba30$9ebc2e90$@com>
References: <puth6t1f6pvl8jnh3in87s79.1284075227979@email.android.com>
	<003f01cb507a$8a3eba30$9ebc2e90$@com>
Message-ID: <4C89925B.2060206@oracle.com>

David Dabbs wrote:
>> Charlie Hunt
>> In general, best practice 
>> use +UseNUMA when the jvm you are launching will span more than one memory node.
>>     
>
> Hi Charlie.
>
> Apologies for my ignorance, but how would I know that this is the case? 
> We're running a servlet container (Tomcat) with no special CPU affinities or numactl.
> So I'm guessing that this qualifies as spanning more than one memory node
>   
Assuming you have a NUMA system, and you are not using any Linux 
commands to control CPU affinity on the JVM running Tomcat, then yes, 
this would qualify for spanning more than one memory node.

hths,

charlie ...

> Thanks!
>
> David
>
>
>
> -----Original Message-----
> From: [mailto:charlie.hunt at sun.com] 
> Sent: Thursday, September 09, 2010 6:34 PM
> To: David Dabbs; hotspot-dev at openjdk.java.net
> Subject: RE: jdk and NUMA
>
> In general, best practice .... use +UseNUMA when the jvm you are launching will span more than one memory node.
>
> Charlie 
>
> David Dabbs <dmdabbs at gmail.com> wrote:
>
>   
>> Thank you ramki, for the reply.
>>
>> What "issues" should might one expect after adding +UseNUMA?
>>
>>
>>
>>
>> -----Original Message-----
>> From: Y. S. Ramakrishna [mailto: @oracle.com] 
>> Sent: Thursday, September 09, 2010 5:31 PM
>> To: David Dabbs
>> Subject: Re: jdk and NUMA
>>
>> Yes, just use +UseNUMA to begin with, and let us know if there are
>> any issues.
>>
>> -- ramki
>>
>> On 09/09/10 12:04, David Dabbs wrote:
>>     
>>> My apologies if this is not the correct place for this question.
>>>
>>> I have a shiny new NUMA-capable Xeon server and want to ensure that my
>>>       
>> Java
>>     
>>> app(s) make full use of the hardware.
>>> So, I ran java (jdk 6u21) -XX:+PrintFlagsFinal and (naively) expected to
>>>       
>> see
>>     
>>> UseNUMA := true but did not.
>>>
>>> I found this post
>>>
>>> http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary
>>>
>>> If its simply a matter of turning it on that's what I'll do. Any
>>>       
>> guidelines
>>     
>>> about use of mumactl or the jdks NUMA "knobs"?
>>>
>>>
>>> uname -a
>>> Linux 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64
>>> x86_64 GNU/Linux
>>>
>>> Linux, CentOS 5
>>>
>>>
>>> cat /proc/cpuinfo
>>>
>>> processor       : 0
>>> vendor_id       : GenuineIntel
>>> cpu family      : 6
>>> model           : 26
>>> model name      : Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz
>>> stepping        : 5
>>> cpu MHz         : 2394.112
>>> cache size      : 8192 KB
>>> physical id     : 1
>>> siblings        : 8
>>> core id         : 0
>>> cpu cores       : 4
>>> apicid          : 16
>>> fpu             : yes
>>> fpu_exception   : yes
>>> cpuid level     : 11
>>> wp              : yes
>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx
>>>       
>> rdtscp
>>     
>>> lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr
>>> popcnt lahf_lm
>>> bogomips        : 4791.64
>>> clflush size    : 64
>>> cache_alignment : 64
>>> address sizes   : 40 bits physical, 48 bits virtual
>>> power management: [8]        
>>>
>>> This repeats for processors 1-15.
>>>
>>> Two physical ids, 0,1.
>>>
>>>
>>>
>>>       
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com 
>> Version: 9.0.851 / Virus Database: 271.1.1/3124 - Release Date: 09/09/10
>> 01:34:00
>>
>>     
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.851 / Virus Database: 271.1.1/3124 - Release Date: 09/09/10 13:34:00
>
>   


From puzzlesdj at gmail.com  Sun Sep 12 15:14:39 2010
From: puzzlesdj at gmail.com (ddmetro)
Date: Sun, 12 Sep 2010 15:14:39 -0700 (PDT)
Subject: help on instruction scheduling of hotspot jvm
Message-ID: <29693457.post@talk.nabble.com>


Hi All,

I am working on multithreaded instruction scheduling on hotspot jvm. I have
built the source code, however I have the following doubts:

1. I tried to look into instruction scheduling pass of Hotspot, but couldn't
find any paper related to the same. Can you please direct me towards a paper
that talks about instruction scheduling and thread scheduling in hotspot
jvm.
2. I executed an applet using the j2sdk image's appletviewer. However, I am
not able to get the starting point (main() method) for the same. Kindly
provide the starting point.
3. I am assuming that the instruction scheduling will be done by the server
side hotspot jvm and not the compiler (C2). Kindly confirm if my
understanding is correct.

Also, I tried to search for documentation that maps the different
phases(instruction scheduling, register allocation, etc) with the source
code classes. However I wasn't able to find one. Kindly direct me to such
documentation, if one exists.

Thanking You,
-Dhiraj.
-- 
View this message in context: http://old.nabble.com/help-on-instruction-scheduling-of-hotspot-jvm-tp29693457p29693457.html
Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com.


From David.Holmes at oracle.com  Sun Sep 12 16:14:29 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 13 Sep 2010 09:14:29 +1000
Subject: help on instruction scheduling of hotspot jvm
In-Reply-To: <29693457.post@talk.nabble.com>
References: <29693457.post@talk.nabble.com>
Message-ID: <4C8D5ED5.8080108@oracle.com>

ddmetro said the following on 09/13/10 08:14:
> I am working on multithreaded instruction scheduling on hotspot jvm. I have
> built the source code, however I have the following doubts:
> 
> 1. I tried to look into instruction scheduling pass of Hotspot, but couldn't
> find any paper related to the same. Can you please direct me towards a paper
> that talks about instruction scheduling and thread scheduling in hotspot
> jvm.

Don't know about instruction scheduling (which is a compiler issue) but 
thread scheduling is basically done using the OS default scheduling 
mechanism. There are some settings you can adjust to change this, and 
you can do things externally (ie run the JVM in particular scheduling 
class) but they are not recommended and need to be used with extreme 
care. Dave Dice has some blog articles on this:

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

> 2. I executed an applet using the j2sdk image's appletviewer. However, I am
> not able to get the starting point (main() method) for the same. Kindly
> provide the starting point.

Applets don't have a main() method. Applets are executed by a framework 
and it is the framework that has the main() method. You'd have to look 
at the AppletViewer class in this case.

> 3. I am assuming that the instruction scheduling will be done by the server
> side hotspot jvm and not the compiler (C2). Kindly confirm if my
> understanding is correct.

The Hotspot "server" VM is the Hotspot VM configured to run the C2 
compiler. (The "client" VM runs the C1 compiler). Any instruction 
scheduling would be done by the compiler, but questions on this are 
better addressed to hotspot-compiler-dev - cc'ed.

> Also, I tried to search for documentation that maps the different
> phases(instruction scheduling, register allocation, etc) with the source
> code classes. However I wasn't able to find one. Kindly direct me to such
> documentation, if one exists.

There is not a lot of documentation for hotspot internals in general. 
Again the compiler folk may be able to point you to documents or blog
entries that discuss this.

HTH

David Holmes

> Thanking You,
> -Dhiraj.

From vladimir.kozlov at oracle.com  Tue Sep 14 14:18:49 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 14 Sep 2010 14:18:49 -0700
Subject: Request for reviews (S): 6984368 Large default heap size does not
	allow to use zero based compressed oops
Message-ID: <4C8FE6B9.6060505@oracle.com>

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

Fixed 6984368: Large default heap size does not allow to use zero based compressed oops

The heap size expression in max_heap_for_compressed_oops()
does not take into account HeapBaseMinAddress value which
is used to get zero based compressed oops.

Also MaxPermSize is rounded up in CollectorPolicy::initialize_flags()
which makes invalid all expressions which use it before rounding.


From tom.rodriguez at oracle.com  Tue Sep 14 17:04:35 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 14 Sep 2010 17:04:35 -0700
Subject: Request for reviews (S): 6984368 Large default heap size does not
	allow to use zero based compressed oops
In-Reply-To: <4C8FE6B9.6060505@oracle.com>
References: <4C8FE6B9.6060505@oracle.com>
Message-ID: <FB5FB0A0-F5BF-408C-B7D0-5F5F715447D7@oracle.com>

Looks ok.

tom

On Sep 14, 2010, at 2:18 PM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/6984368/webrev
> 
> Fixed 6984368: Large default heap size does not allow to use zero based compressed oops
> 
> The heap size expression in max_heap_for_compressed_oops()
> does not take into account HeapBaseMinAddress value which
> is used to get zero based compressed oops.
> 
> Also MaxPermSize is rounded up in CollectorPolicy::initialize_flags()
> which makes invalid all expressions which use it before rounding.
> 


From vladimir.kozlov at oracle.com  Tue Sep 14 17:05:36 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 14 Sep 2010 17:05:36 -0700
Subject: Request for reviews (S): 6984368 Large default heap size does
	not allow to use zero based compressed oops
In-Reply-To: <FB5FB0A0-F5BF-408C-B7D0-5F5F715447D7@oracle.com>
References: <4C8FE6B9.6060505@oracle.com>
	<FB5FB0A0-F5BF-408C-B7D0-5F5F715447D7@oracle.com>
Message-ID: <4C900DD0.5050805@oracle.com>

Thanks, Tom

Vladimir

Tom Rodriguez wrote:
> Looks ok.
> 
> tom
> 
> On Sep 14, 2010, at 2:18 PM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/6984368/webrev
>>
>> Fixed 6984368: Large default heap size does not allow to use zero based compressed oops
>>
>> The heap size expression in max_heap_for_compressed_oops()
>> does not take into account HeapBaseMinAddress value which
>> is used to get zero based compressed oops.
>>
>> Also MaxPermSize is rounded up in CollectorPolicy::initialize_flags()
>> which makes invalid all expressions which use it before rounding.
>>
> 

From sylvestre.ledru at scilab.org  Wed Sep 15 00:17:50 2010
From: sylvestre.ledru at scilab.org (Sylvestre Ledru)
Date: Wed, 15 Sep 2010 09:17:50 +0200
Subject: Unknown error reported in the JNI "JNI_CreateJavaVM"
Message-ID: <1284535070.17296.214.camel@korcula.inria.fr>

Hello,

As suggested in the bug report:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=553
I am contacting you about an small issue.

Starting the JVM a few times with "JNI_CreateJavaVM" may lead to an
error JNI_ERR ("unknown error").
However, it could return JNI_EEXIST ("VM already created") which will be
more interesting to manage the error and debugging. This error code is
already defined in jni.h.

Thanks for considering the (tiny) patch.

Regards,
Sylvestre




-------------- next part --------------
A non-text attachment was scrubbed...
Name: use_eexist_JNI_CreateJavaVM.diff
Type: text/x-patch
Size: 624 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100915/7e12e514/attachment.bin 

From David.Holmes at oracle.com  Wed Sep 15 00:43:46 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 15 Sep 2010 17:43:46 +1000
Subject: Unknown error reported in the JNI "JNI_CreateJavaVM"
In-Reply-To: <1284535070.17296.214.camel@korcula.inria.fr>
References: <1284535070.17296.214.camel@korcula.inria.fr>
Message-ID: <4C907932.2090402@oracle.com>

Sylvestre Ledru said the following on 09/15/10 17:17:
> As suggested in the bug report:
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=553
> I am contacting you about an small issue.
> 
> Starting the JVM a few times with "JNI_CreateJavaVM" may lead to an
> error JNI_ERR ("unknown error").
> However, it could return JNI_EEXIST ("VM already created") which will be
> more interesting to manage the error and debugging. This error code is
> already defined in jni.h.

This is a curious part of the JNI spec as it doesn't actually define a 
set of error codes, even though jni.h does contain a few, including 
JNI_EEXIST. But at least we aren't constrained by the spec as 
CreateJavaVM is allowed to return a "a suitable JNI error code (a 
negative number) on failure".

The question is, is it too late to change this? Any code that checks for 
JNI_ERR will now be broken, but code that checks for !JNI_OK will be fine.

David Holmes

> Thanks for considering the (tiny) patch.
> 
> Regards,
> Sylvestre
> 
> 
> 
> 
> 

From keith.mcguigan at oracle.com  Wed Sep 15 16:39:23 2010
From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com)
Date: Wed, 15 Sep 2010 23:39:23 +0000
Subject: hg: jdk7/hotspot/hotspot: 3 new changesets
Message-ID: <20100915233931.6D5C0479DA@hg.openjdk.java.net>

Changeset: ea175c1b79ce
Author:    dcubed
Date:      2010-09-08 08:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ea175c1b79ce

6561870: 3/3 Long javac compile lines fail due to command line length issues (agent compiles?)
Summary: Use javac's @filename construct to avoid long compile lines
Reviewed-by: ohair, twisti, never
Contributed-by: doko at ubuntu.com

! make/linux/makefiles/sa.make
! make/solaris/makefiles/sa.make

Changeset: 30f67acf635d
Author:    thurka
Date:      2010-09-11 08:18 +0200
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/30f67acf635d

6765718: Indicate which thread throwing OOME when generating the heap dump at OOME
Summary: Emit a fake frame that makes it look like the thread is in the OutOfMemoryError zero-parameter constructor
Reviewed-by: dcubed

! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/heapDumper.hpp
! src/share/vm/utilities/debug.cpp

Changeset: 8a8a7a014a12
Author:    kamg
Date:      2010-09-13 07:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8a8a7a014a12

Merge



From vladimir.kozlov at oracle.com  Thu Sep 16 10:12:30 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 16 Sep 2010 10:12:30 -0700
Subject: Review request 6985422: flush the output streams before OnError
	commands
Message-ID: <4C924FFE.607@oracle.com>

http://cr.openjdk.java.net/~rasbold/OnError/webrev.00

When the VM aborts, flush the output streams before
OnError commands are processed. Log files will not be
flushed if SuppressFatalErrorMessage is used to avoid
all post fatal error processing.

Contributed-by: rasbold at google.com


From tom.rodriguez at oracle.com  Thu Sep 16 11:21:25 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 16 Sep 2010 11:21:25 -0700
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <4C924FFE.607@oracle.com>
References: <4C924FFE.607@oracle.com>
Message-ID: <41354AC3-7CCB-46FB-B8B9-66989129079C@oracle.com>

Looks good.

tom

On Sep 16, 2010, at 10:12 AM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~rasbold/OnError/webrev.00
> 
> When the VM aborts, flush the output streams before
> OnError commands are processed. Log files will not be
> flushed if SuppressFatalErrorMessage is used to avoid
> all post fatal error processing.
> 
> Contributed-by: rasbold at google.com
> 


From vladimir.kozlov at oracle.com  Thu Sep 16 11:24:39 2010
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 16 Sep 2010 11:24:39 -0700
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <41354AC3-7CCB-46FB-B8B9-66989129079C@oracle.com>
References: <4C924FFE.607@oracle.com>
	<41354AC3-7CCB-46FB-B8B9-66989129079C@oracle.com>
Message-ID: <4C9260E7.8000001@oracle.com>

Thank you, Tom

Vladimir

Tom Rodriguez wrote:
> Looks good.
> 
> tom
> 
> On Sep 16, 2010, at 10:12 AM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~rasbold/OnError/webrev.00
>>
>> When the VM aborts, flush the output streams before
>> OnError commands are processed. Log files will not be
>> flushed if SuppressFatalErrorMessage is used to avoid
>> all post fatal error processing.
>>
>> Contributed-by: rasbold at google.com
>>
> 

From staffan.larsen at oracle.com  Thu Sep 16 11:47:00 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 16 Sep 2010 11:47:00 -0700 (PDT)
Subject: Review request 6981484: Update development launcher
Message-ID: <41c46841-693e-4bed-ac89-29cff7867a50@default>

http://cr.openjdk.java.net/~sla/6981484/webrev.00/

Update the development launcher (gamma) to 
  1) not require env.sh to be sourced before launching
  2) not require the current working directory to be the build directory
  3) exist on windows platforms as well
  4) support launching a debugger with -gdb/-gud (linux) or -dbx (solaris)

A few notes about the implementation:
- I did not change the current gamma launcher, but chose to add a new "frontend" to it called "fusion". This is a script that sets up the necessary environment. This was to avoid changing something that works.
- The launcher should really share code across platforms instead of being in os/<os>/launcher, but I wanted to keep the changes small.
- The launcher code for Windows is a copy of the launcher found in 6u22 with changes (#ifndef GAMMA)

Thanks,
/Staffan

From David.Holmes at oracle.com  Thu Sep 16 16:57:05 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 17 Sep 2010 09:57:05 +1000
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <4C924FFE.607@oracle.com>
References: <4C924FFE.607@oracle.com>
Message-ID: <4C92AED1.3010906@oracle.com>

Vladimir Kozlov said the following on 09/17/10 03:12:
> http://cr.openjdk.java.net/~rasbold/OnError/webrev.00
> 
> When the VM aborts, flush the output streams before
> OnError commands are processed. Log files will not be
> flushed if SuppressFatalErrorMessage is used to avoid
> all post fatal error processing.

Why was the ostream_abort() removed from the os::shutdown() path?

In the existing code we have:

VMError::report_and_die()
  -> os::abort()
     -> os::shutdown()
        -> ostream_abort()

and you've moved ostream_abort() into report_and_die(), but there are 
other exit paths that also call os::shutdown() and will no longer call 
ostream_abort():

vm_shutdown_during_initialization()
-> vm_shutdown()
     -> os::shutdown()

Also with this move you need to fix this comment in ostream.cpp:

// ostream_abort() is called by os::abort() when VM is about to die.
void ostream_abort() {

Why not just add explicit flush() calls where needed?

David Holmes

> Contributed-by: rasbold at google.com
> 

From vladimir.kozlov at oracle.com  Thu Sep 16 17:22:22 2010
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Fri, 17 Sep 2010 00:22:22 +0000
Subject: hg: jdk7/hotspot/jdk: 4 new changesets
Message-ID: <20100917002311.CE9B647A1E@hg.openjdk.java.net>

Changeset: 48f0b94573c8
Author:    jrose
Date:      2010-09-08 18:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/48f0b94573c8

6964498: JSR 292 invokedynamic sites need local bootstrap methods
Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs; add MethodHandleProvider.
Reviewed-by: twisti

+ src/share/classes/java/dyn/BootstrapMethod.java
! src/share/classes/java/dyn/CallSite.java
+ src/share/classes/java/dyn/ConstantCallSite.java
! src/share/classes/java/dyn/InvokeDynamic.java
! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java
! src/share/classes/java/dyn/Linkage.java
! src/share/classes/java/dyn/LinkagePermission.java
! src/share/classes/java/dyn/MethodHandle.java
+ src/share/classes/java/dyn/MethodHandleProvider.java
! src/share/classes/java/dyn/package-info.java
! src/share/classes/sun/dyn/CallSiteImpl.java
! test/java/dyn/MethodHandlesTest.java

Changeset: d30ca8bcad63
Author:    jrose
Date:      2010-09-08 18:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d30ca8bcad63

6980096: JSR 292 reflective lookup should throw checked exceptions
Summary: Make NoAccessException be a checked exception.  Also remove JavaMethodHandle.
Reviewed-by: twisti

! src/share/classes/java/dyn/CallSite.java
- src/share/classes/java/dyn/JavaMethodHandle.java
! src/share/classes/java/dyn/MethodHandles.java
! src/share/classes/java/dyn/MethodType.java
! src/share/classes/java/dyn/NoAccessException.java
! src/share/classes/sun/dyn/BoundMethodHandle.java
! src/share/classes/sun/dyn/CallSiteImpl.java
! src/share/classes/sun/dyn/FilterGeneric.java
! src/share/classes/sun/dyn/FilterOneArgument.java
! src/share/classes/sun/dyn/FromGeneric.java
! src/share/classes/sun/dyn/Invokers.java
+ src/share/classes/sun/dyn/JavaMethodHandle.java
! src/share/classes/sun/dyn/MemberName.java
! src/share/classes/sun/dyn/MethodHandleImpl.java
! src/share/classes/sun/dyn/MethodHandleNatives.java
! src/share/classes/sun/dyn/SpreadGeneric.java
! src/share/classes/sun/dyn/ToGeneric.java
! src/share/classes/sun/dyn/util/ValueConversions.java
+ test/java/dyn/JavaDocExamples.java
! test/java/dyn/MethodHandlesTest.java

Changeset: 93f36769ecef
Author:    jrose
Date:      2010-09-08 18:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/93f36769ecef

6953246: JSR 292 should support SAM conversion
Summary: Conversion function MethodHandles.asInstance; initial slow implementation based on Proxy.
Reviewed-by: twisti

! src/share/classes/java/dyn/MethodHandles.java
! test/java/dyn/MethodHandlesTest.java

Changeset: 4ed243e9e9d9
Author:    jrose
Date:      2010-09-14 01:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4ed243e9e9d9

6982752: dynamic languages need to decorate types with runtime information
Summary: Add ClassValue
Reviewed-by: twisti

+ src/share/classes/java/dyn/ClassValue.java
+ test/java/dyn/ClassValueTest.java


From rasbold at google.com  Fri Sep 17 10:07:57 2010
From: rasbold at google.com (Chuck Rasbold)
Date: Fri, 17 Sep 2010 10:07:57 -0700
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <4C92AED1.3010906@oracle.com>
References: <4C924FFE.607@oracle.com>
	<4C92AED1.3010906@oracle.com>
Message-ID: <AANLkTik_boQfAtzRX2aLA_NKs4yv4fevT1NUgRP0kQd9@mail.gmail.com>

On Thu, Sep 16, 2010 at 4:57 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Vladimir Kozlov said the following on 09/17/10 03:12:
>
>  http://cr.openjdk.java.net/~rasbold/OnError/webrev.00
>>
>> When the VM aborts, flush the output streams before
>> OnError commands are processed. Log files will not be
>> flushed if SuppressFatalErrorMessage is used to avoid
>> all post fatal error processing.
>>
>
> Why was the ostream_abort() removed from the os::shutdown() path?
>
> In the existing code we have:
>
> VMError::report_and_die()
>  -> os::abort()
>    -> os::shutdown()
>       -> ostream_abort()
>

It seems backward to me the the os-specific abort() calls ostream_abort().

Ostream_init() and ostream_init_log() are called from create_vm(), I think
it would be preferable to clean-up the ostreams at a similar level.


> and you've moved ostream_abort() into report_and_die(), but there are other
> exit paths that also call os::shutdown() and will no longer call
> ostream_abort():
>
> vm_shutdown_during_initialization()
> -> vm_shutdown()
>    -> os::shutdown()
>
>
Agreed that I missed vm_shutdown() in java.cpp.   I'd be happy to add a call
to ostream_abort() there.

Are there other call sites to os:shutdown() that I've missed?  If so,
perhaps it is safer to leave the originals calls in os::abort() as I've
underestimated the complexity of the shutdown code.

Also with this move you need to fix this comment in ostream.cpp:
>
> // ostream_abort() is called by os::abort() when VM is about to die.
> void ostream_abort() {
>
>
True.


> Why not just add explicit flush() calls where needed?
>

Flushing is pretty much what ostream_abort() does.  The compilation log
flushing code is short but non-trivial.  I think it is best not duplicate
the it.

-- Chuck


> David Holmes
>
>
>  Contributed-by: rasbold at google.com
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100917/4fb311aa/attachment.html 

From john.cuthbertson at oracle.com  Fri Sep 17 13:03:42 2010
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Fri, 17 Sep 2010 20:03:42 +0000
Subject: hg: jdk7/hotspot/hotspot: 5 new changesets
Message-ID: <20100917200352.CB61847A65@hg.openjdk.java.net>

Changeset: 179464550c7d
Author:    ysr
Date:      2010-09-10 17:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/179464550c7d

6983930: CMS: Various small cleanups ca September 2010
Summary: Fixed comment/documentation typos; converted some guarantee()s to assert()s.
Reviewed-by: jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp
! src/share/vm/runtime/globals.hpp

Changeset: eeade8e89248
Author:    ysr
Date:      2010-09-11 11:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eeade8e89248

Merge

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

Changeset: 6eddcbe17c83
Author:    johnc
Date:      2010-09-13 10:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6eddcbe17c83

6981746: G1: SEGV with -XX:+TraceGen0Time
Summary: Pass correct value for length to NumberSeq constructor. Guard dereferences of "body_summary" pointer with a NULL check.
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp

Changeset: 432d823638f7
Author:    jcoomes
Date:      2010-09-15 10:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/432d823638f7

6985022: update make/jprt.properties for new jdk7 tools
Reviewed-by: ohair, kvn

! make/jprt.properties

Changeset: 97fbf5beff7b
Author:    johnc
Date:      2010-09-16 13:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/97fbf5beff7b

Merge



From daniel.daugherty at oracle.com  Fri Sep 17 13:31:38 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 17 Sep 2010 14:31:38 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C818EEB.7030107@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>
	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
	<4C818EEB.7030107@oracle.com>
Message-ID: <4C93D02A.4000009@oracle.com>

Greetings,

The fix for this bug (6561870) has caused the sa-jdi.jar file to
always be rebuilt. I have a minor tweak that fixes that problem:

    http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/

Thanks to Coleen for spotting this issue!

The folks on the "To" list were on the original review team
for 6561870. I would like to hear from at least two of those
folks on this tweak.

Thanks, in advance, for the reviews!

Dan



On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
> Here is the revised webrev:
>
> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>
> One reviewer will do, I think...
>
> Dan
>
>
> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  
>> Otherwise this looks good.
>>
>> tom
>>
>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>
>>  
>>> I'm finally getting back to this thread. Since I'm also applying
>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>> send out a webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>
>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>
>>> Matthias, can you verify that I got the Solaris port of your
>>> changes correct?
>>>
>>> Thanks, in advance, for any reviews...
>>>
>>> Dan
>>>
>>>
>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>    
>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>      
>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>
>>>>>        
>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>
>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>> would ask...
>>>>>>              
>>>>> Yeah, I also thought about this for Solaris and it should work 
>>>>> there as
>>>>> on Linux.  Don't know about Windows, though.
>>>>>  
>>>>>         
>>>> Looks like Windows already uses a "make" construct instead of running
>>>> into the shell command line limitation:
>>>>
>>>>      
>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>         
>>>> <snip>
>>>>
>>>>      
>>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>> $(SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>> $(SA_CLASSPATH) -so
>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>         
>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>> leave the Windows stuff alone :-)
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>       
>>
>>
>>   
>

From dmdabbs at gmail.com  Fri Sep 17 14:26:18 2010
From: dmdabbs at gmail.com (David Dabbs)
Date: Fri, 17 Sep 2010 16:26:18 -0500
Subject: jdk7/hotspot/hotspot: 5 new changesets
In-Reply-To: <20100917200352.CB61847A65@hg.openjdk.java.net>
References: <20100917200352.CB61847A65@hg.openjdk.java.net>
Message-ID: <00ff01cb56ae$f852df30$e8f89d90$@com>


The JDK7 release page shows b110 source available, but binary at b109.
Does this mean that b110 binaries are awaiting soon-to-be committed
changesets?
If so, does that make the b110 downloadable source bundle invalid?
Ditto for the binaries you can get if you edit the build number and date in
the urls?  ;-)

Thanks,

david




From tom.rodriguez at oracle.com  Fri Sep 17 15:44:57 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 17 Sep 2010 15:44:57 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C93D02A.4000009@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>
	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
	<4C818EEB.7030107@oracle.com> <4C93D02A.4000009@oracle.com>
Message-ID: <3DC0116E-3CAC-4FD2-971F-4F17C1555E07@oracle.com>

Looks good.

tom

On Sep 17, 2010, at 1:31 PM, Daniel D. Daugherty wrote:

> Greetings,
> 
> The fix for this bug (6561870) has caused the sa-jdi.jar file to
> always be rebuilt. I have a minor tweak that fixes that problem:
> 
>   http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
> 
> Thanks to Coleen for spotting this issue!
> 
> The folks on the "To" list were on the original review team
> for 6561870. I would like to hear from at least two of those
> folks on this tweak.
> 
> Thanks, in advance, for the reviews!
> 
> Dan
> 
> 
> 
> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>> Here is the revised webrev:
>> 
>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>> 
>> One reviewer will do, I think...
>> 
>> Dan
>> 
>> 
>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>>> 
>>> tom
>>> 
>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>> 
>>> 
>>>> I'm finally getting back to this thread. Since I'm also applying
>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>> send out a webrev:
>>>> 
>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>> 
>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>> 
>>>> Matthias, can you verify that I got the Solaris port of your
>>>> changes correct?
>>>> 
>>>> Thanks, in advance, for any reviews...
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>   
>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>     
>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>> 
>>>>>>       
>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>> 
>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>> would ask...
>>>>>>>             
>>>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>         
>>>>> Looks like Windows already uses a "make" construct instead of running
>>>>> into the shell command line limitation:
>>>>> 
>>>>>     
>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>        
>>>>> <snip>
>>>>> 
>>>>>     
>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>        
>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>>> leave the Windows stuff alone :-)
>>>>> 
>>>>> Dan
>>>>> 
>>>>> 
>>>>> 
>>>>>      
>>> 
>>> 
>>>  
>> 


From vladimir.kozlov at oracle.com  Fri Sep 17 16:14:14 2010
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Fri, 17 Sep 2010 23:14:14 +0000
Subject: hg: jdk7/hotspot/hotspot: 15 new changesets
Message-ID: <20100917231442.DD1A547A71@hg.openjdk.java.net>

Changeset: f353275af40e
Author:    never
Date:      2010-09-02 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f353275af40e

6981773: incorrect fill value with OptimizeFill
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/stubGenerator_sparc.cpp

Changeset: d5d065957597
Author:    iveresov
Date:      2010-09-03 17:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d5d065957597

6953144: Tiered compilation
Summary: Infrastructure for tiered compilation support (interpreter + c1 + c2) for 32 and 64 bit. Simple tiered policy implementation.
Reviewed-by: kvn, never, phh, twisti

! make/linux/Makefile
! make/solaris/Makefile
+ make/solaris/makefiles/reorder_TIERED_sparcv9
! make/windows/build.make
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/c1_globals_sparc.hpp
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/c1_globals_x86.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Compiler.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_Instruction.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.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_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/includeDB_compiler1
! src/share/vm/includeDB_compiler2
! src/share/vm/includeDB_core
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/invocationCounter.cpp
! src/share/vm/interpreter/invocationCounter.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/methodDataOop.cpp
! src/share/vm/oops/methodDataOop.hpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/dtraceJSDT.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/safepoint.hpp
+ src/share/vm/runtime/simpleThresholdPolicy.cpp
+ src/share/vm/runtime/simpleThresholdPolicy.hpp
+ src/share/vm/runtime/simpleThresholdPolicy.inline.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/macros.hpp

Changeset: ac4f710073ed
Author:    iveresov
Date:      2010-09-07 14:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ac4f710073ed

6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod
Summary: Assertion fails during print compilation because nmethod::print_on() calls osr_entry_bci() without checking that the method is an osr method. The fix adds an appropriate check.
Reviewed-by: never, twisti

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

Changeset: 5e4f03302987
Author:    never
Date:      2010-09-07 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5e4f03302987

6982533: Crash in  ~StubRoutines::jbyte_fill with AggressiveOpts enabled
Reviewed-by: kvn

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

Changeset: f9883ee8ce39
Author:    never
Date:      2010-09-08 20:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f9883ee8ce39

6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000
Reviewed-by: kvn

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

Changeset: 84713fd87632
Author:    twisti
Date:      2010-09-08 04:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/84713fd87632

6983073: fix compiler error with GCC 4.4 or newer on SPARC
Reviewed-by: twisti
Contributed-by: Matthias Klose <doko at ubuntu.com>

! src/cpu/sparc/vm/frame_sparc.hpp

Changeset: 33a54060190d
Author:    twisti
Date:      2010-09-09 01:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/33a54060190d

Merge


Changeset: a83b0246bb77
Author:    twisti
Date:      2010-09-09 05:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a83b0246bb77

6934483: GCC 4.5 errors "suggest parentheses around something..." when compiling with -Werror and -Wall
Summary: These are minor changes fixing compile failure when -Wall -Werror flags are used under gcc 4.5.
Reviewed-by: twisti, kvn, rasbold
Contributed-by: Pavel Tisnovsky <ptisnovs at redhat.com>

! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 7f9553bedfd5
Author:    iveresov
Date:      2010-09-11 15:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7f9553bedfd5

6984056: C1: incorrect code for integer constant addition on x64
Summary: Fix add/sub of constants to ints on x64
Reviewed-by: kvn

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 3a294e483abc
Author:    iveresov
Date:      2010-09-13 12:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3a294e483abc

6919069: client compiler needs to capture more profile information for tiered work
Summary: Added profiling of instanceof and aastore.
Reviewed-by: kvn, jrose, never

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! 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_Canonicalizer.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.hpp

Changeset: d20603ee9e10
Author:    kvn
Date:      2010-09-13 16:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d20603ee9e10

6984346: Remove development code in type.hpp
Summary: Remove code which use UseNewCode in type.hpp
Reviewed-by: never

! src/share/vm/opto/type.hpp

Changeset: d257356e35f0
Author:    jrose
Date:      2010-09-13 23:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d257356e35f0

6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions
Reviewed-by: never

! src/cpu/sparc/vm/stubRoutines_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 065dd1ca3ab6
Author:    never
Date:      2010-09-14 14:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/065dd1ca3ab6

6982370: SIGBUS in jbyte_fill
Reviewed-by: kvn

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
+ test/compiler/6982370/Test6982370.java

Changeset: a8b66e00933b
Author:    kvn
Date:      2010-09-14 17:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a8b66e00933b

6984368: Large default heap size does not allow to use zero based compressed oops
Summary: take into account HeapBaseMinAddress and round down MaxPermSize
Reviewed-by: never

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

Changeset: 18c378513575
Author:    kvn
Date:      2010-09-16 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/18c378513575

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/macros.hpp


From daniel.daugherty at oracle.com  Fri Sep 17 16:38:19 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 17 Sep 2010 17:38:19 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <3DC0116E-3CAC-4FD2-971F-4F17C1555E07@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>
	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>
	<4C818EEB.7030107@oracle.com> <4C93D02A.4000009@oracle.com>
	<3DC0116E-3CAC-4FD2-971F-4F17C1555E07@oracle.com>
Message-ID: <4C93FBEB.4050407@oracle.com>

Thanks Tom!

Dan


On 9/17/2010 4:44 PM, Tom Rodriguez wrote:
> Looks good.
>
> tom
>
> On Sep 17, 2010, at 1:31 PM, Daniel D. Daugherty wrote:
>
>   
>> Greetings,
>>
>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>> always be rebuilt. I have a minor tweak that fixes that problem:
>>
>>   http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>
>> Thanks to Coleen for spotting this issue!
>>
>> The folks on the "To" list were on the original review team
>> for 6561870. I would like to hear from at least two of those
>> folks on this tweak.
>>
>> Thanks, in advance, for the reviews!
>>
>> Dan
>>
>>
>>
>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>     
>>> Here is the revised webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>
>>> One reviewer will do, I think...
>>>
>>> Dan
>>>
>>>
>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>       
>>>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>>>>
>>>> tom
>>>>
>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>
>>>>
>>>>         
>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>> send out a webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>
>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>
>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>> changes correct?
>>>>>
>>>>> Thanks, in advance, for any reviews...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>   
>>>>>           
>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>     
>>>>>>             
>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>
>>>>>>>       
>>>>>>>               
>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>
>>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>> would ask...
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>         
>>>>>>>               
>>>>>> Looks like Windows already uses a "make" construct instead of running
>>>>>> into the shell command line limitation:
>>>>>>
>>>>>>     
>>>>>>             
>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>>        
>>>>>>>               
>>>>>> <snip>
>>>>>>
>>>>>>     
>>>>>>             
>>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>>        
>>>>>>>               
>>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>>>> leave the Windows stuff alone :-)
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>      
>>>>>>             
>>>>  
>>>>         
>
>   

From daniel.daugherty at ORACLE.COM  Fri Sep 17 21:49:35 2010
From: daniel.daugherty at ORACLE.COM (Daniel D. Daugherty)
Date: Fri, 17 Sep 2010 22:49:35 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C93D02A.4000009@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com>
Message-ID: <4C9444DF.5050807@oracle.com>

I messed up the rule expansion... :-(

Here's another shot:

http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/

This time I added a comment so the subtle difference
between macro/variable expansion versus rule execution
is a little more clear. I hope...

Dan



On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> The fix for this bug (6561870) has caused the sa-jdi.jar file to
> always be rebuilt. I have a minor tweak that fixes that problem:
>
>    http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>
> Thanks to Coleen for spotting this issue!
>
> The folks on the "To" list were on the original review team
> for 6561870. I would like to hear from at least two of those
> folks on this tweak.
>
> Thanks, in advance, for the reviews!
>
> Dan
>
>
>
> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>> Here is the revised webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>
>> One reviewer will do, I think...
>>
>> Dan
>>
>>
>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  
>>> Otherwise this looks good.
>>>
>>> tom
>>>
>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>
>>>  
>>>> I'm finally getting back to this thread. Since I'm also applying
>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>> send out a webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>
>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>
>>>> Matthias, can you verify that I got the Solaris port of your
>>>> changes correct?
>>>>
>>>> Thanks, in advance, for any reviews...
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>   
>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>     
>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>
>>>>>>       
>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>
>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>> would ask...
>>>>>>>              
>>>>>> Yeah, I also thought about this for Solaris and it should work 
>>>>>> there as
>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>  
>>>>>>         
>>>>> Looks like Windows already uses a "make" construct instead of running
>>>>> into the shell command line limitation:
>>>>>
>>>>>     
>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>         
>>>>> <snip>
>>>>>
>>>>>     
>>>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>> $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>        @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>> $(SA_CLASSPATH) -so
>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>         
>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>>> leave the Windows stuff alone :-)
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>       
>>>
>>>
>>>   
>>
>

From kelly.ohair at oracle.com  Sun Sep 19 13:08:40 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Sun, 19 Sep 2010 13:08:40 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C9444DF.5050807@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
Message-ID: <1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>

Why are you using
     $(shell rm -f -r ... )
instead of
    $(RM) -r ...

???


On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:

> I messed up the rule expansion... :-(
>
> Here's another shot:
>
> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>
> This time I added a comment so the subtle difference
> between macro/variable expansion versus rule execution
> is a little more clear. I hope...
>
> Dan
>
>
>
> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>> always be rebuilt. I have a minor tweak that fixes that problem:
>>
>>   http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>
>> Thanks to Coleen for spotting this issue!
>>
>> The folks on the "To" list were on the original review team
>> for 6561870. I would like to hear from at least two of those
>> folks on this tweak.
>>
>> Thanks, in advance, for the reviews!
>>
>> Dan
>>
>>
>>
>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>> Here is the revised webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>
>>> One reviewer will do, I think...
>>>
>>> Dan
>>>
>>>
>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>> Can the agent list files go into $(GENERATED) instead of $ 
>>>> (TOPDIR)?  Otherwise this looks good.
>>>>
>>>> tom
>>>>
>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>
>>>>
>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>> send out a webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>
>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>
>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>> changes correct?
>>>>>
>>>>> Thanks, in advance, for any reviews...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>
>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>
>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>
>>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>> would ask...
>>>>>>>>
>>>>>>> Yeah, I also thought about this for Solaris and it should work  
>>>>>>> there as
>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>
>>>>>> Looks like Windows already uses a "make" construct instead of  
>>>>>> running
>>>>>> into the shell command line limitation:
>>>>>>
>>>>>>
>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>
>>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>> (SA_CLASSPATH) -so
>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>> (SA_CLASSPATH) -so
>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>>
>>>>>> I also think this is an "nmake" Makefile instead of a GNU  
>>>>>> Makefile.
>>>>>> I think I'll look at applying the changes to the Solaris  
>>>>>> Makefile and
>>>>>> leave the Windows stuff alone :-)
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>


From daniel.daugherty at oracle.com  Sun Sep 19 16:19:08 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Sun, 19 Sep 2010 17:19:08 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
Message-ID: <4C969A6C.9060002@oracle.com>

I guess that three line comment before that block doesn't do
the job. :-(  Can you please suggest a change to the comment
to make it more clear.

The file lists are generated at variable expansion time so we
have to do the remove at variable expansion time also. The
round 0 fix for 6985848 did the remove as a part of rule
execution, but that's too late and causes the javac to fail.

Dan


On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
> Why are you using
>     $(shell rm -f -r ... )
> instead of
>    $(RM) -r ...
>
> ???
>
>
> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>
>> I messed up the rule expansion... :-(
>>
>> Here's another shot:
>>
>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>
>> This time I added a comment so the subtle difference
>> between macro/variable expansion versus rule execution
>> is a little more clear. I hope...
>>
>> Dan
>>
>>
>>
>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>>> always be rebuilt. I have a minor tweak that fixes that problem:
>>>
>>>   http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>
>>> Thanks to Coleen for spotting this issue!
>>>
>>> The folks on the "To" list were on the original review team
>>> for 6561870. I would like to hear from at least two of those
>>> folks on this tweak.
>>>
>>> Thanks, in advance, for the reviews!
>>>
>>> Dan
>>>
>>>
>>>
>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>> Here is the revised webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>
>>>> One reviewer will do, I think...
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>> Can the agent list files go into $(GENERATED) instead of 
>>>>> $(TOPDIR)?  Otherwise this looks good.
>>>>>
>>>>> tom
>>>>>
>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>
>>>>>
>>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>>> send out a webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>
>>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>>
>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>> changes correct?
>>>>>>
>>>>>> Thanks, in advance, for any reviews...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>
>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>
>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>
>>>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>>> would ask...
>>>>>>>>>
>>>>>>>> Yeah, I also thought about this for Solaris and it should work 
>>>>>>>> there as
>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>
>>>>>>> Looks like Windows already uses a "make" construct instead of 
>>>>>>> running
>>>>>>> into the shell command line limitation:
>>>>>>>
>>>>>>>
>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>
>>>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>>>> $(SA_CLASSPATH) -so
>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>>>       @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>>>> $(SA_CLASSPATH) -so
>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>>>
>>>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>>>> I think I'll look at applying the changes to the Solaris 
>>>>>>> Makefile and
>>>>>>> leave the Windows stuff alone :-)
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>

From kelly.ohair at oracle.com  Sun Sep 19 16:49:31 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Sun, 19 Sep 2010 16:49:31 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C969A6C.9060002@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
	<4C969A6C.9060002@oracle.com>
Message-ID: <17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>


On Sep 19, 2010, at 4:19 PM, Daniel D. Daugherty wrote:

> I guess that three line comment before that block doesn't do
> the job. :-(  Can you please suggest a change to the comment
> to make it more clear.
>

Oh, ok, looking at it closer....  this particular make rule evaluation  
characteristics is a bit unknown.
I doubt many people will understand what is happening here.
I guess I would have said something more to the point for the typical  
person:
   "The '$(shell rm)' instead of $(RM) here is critical due to the  
foreach use in the rules."

> The file lists are generated at variable expansion time so we
> have to do the remove at variable expansion time also. The
> round 0 fix for 6985848 did the remove as a part of rule
> execution, but that's too late and causes the javac to fail.

The fact that AGENT_FILES1 and AGENT_FILES2 contains wildcards. I'm  
suspecting a simple:
find $(AGENT_SRC_DIR) -type f -name \*.java > list
would work just as well, assuming the agent sources in the repository  
all need to be built.
But I know you are just trying to fix one issue and not redesign the  
sa makefiles.

Your change should work.

-kto

>
> Dan
>
>
> On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
>> Why are you using
>>    $(shell rm -f -r ... )
>> instead of
>>   $(RM) -r ...
>>
>> ???
>>
>>
>> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>>
>>> I messed up the rule expansion... :-(
>>>
>>> Here's another shot:
>>>
>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>>
>>> This time I added a comment so the subtle difference
>>> between macro/variable expansion versus rule execution
>>> is a little more clear. I hope...
>>>
>>> Dan
>>>
>>>
>>>
>>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>>>> always be rebuilt. I have a minor tweak that fixes that problem:
>>>>
>>>>  http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>>
>>>> Thanks to Coleen for spotting this issue!
>>>>
>>>> The folks on the "To" list were on the original review team
>>>> for 6561870. I would like to hear from at least two of those
>>>> folks on this tweak.
>>>>
>>>> Thanks, in advance, for the reviews!
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>>> Here is the revised webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>>
>>>>> One reviewer will do, I think...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>>> Can the agent list files go into $(GENERATED) instead of $ 
>>>>>> (TOPDIR)?  Otherwise this looks good.
>>>>>>
>>>>>> tom
>>>>>>
>>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>>
>>>>>>
>>>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>>>> send out a webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>>
>>>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>>>
>>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>>> changes correct?
>>>>>>>
>>>>>>> Thanks, in advance, for any reviews...
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>>
>>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>>
>>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>>
>>>>>>>>>> Is there a reason to not apply these changes to the solaris  
>>>>>>>>>> and
>>>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>>>> would ask...
>>>>>>>>>>
>>>>>>>>> Yeah, I also thought about this for Solaris and it should  
>>>>>>>>> work there as
>>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>>
>>>>>>>> Looks like Windows already uses a "make" construct instead of  
>>>>>>>> running
>>>>>>>> into the shell command line limitation:
>>>>>>>>
>>>>>>>>
>>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/ 
>>>>>>>>> =\)
>>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>
>>>>>>>>>      @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>>>> (SA_CLASSPATH) -so
>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/= 
>>>>>>>>> \)
>>>>>>>>>      @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>>>> (SA_CLASSPATH) -so
>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/= 
>>>>>>>>> \)
>>>>>>>>>
>>>>>>>> I also think this is an "nmake" Makefile instead of a GNU  
>>>>>>>> Makefile.
>>>>>>>> I think I'll look at applying the changes to the Solaris  
>>>>>>>> Makefile and
>>>>>>>> leave the Windows stuff alone :-)
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>


From David.Holmes at oracle.com  Sun Sep 19 23:48:50 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 20 Sep 2010 16:48:50 +1000
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <AANLkTik_boQfAtzRX2aLA_NKs4yv4fevT1NUgRP0kQd9@mail.gmail.com>
References: <4C924FFE.607@oracle.com>	<4C92AED1.3010906@oracle.com>
	<AANLkTik_boQfAtzRX2aLA_NKs4yv4fevT1NUgRP0kQd9@mail.gmail.com>
Message-ID: <4C9703D2.9080701@oracle.com>

Chuck Rasbold said the following on 09/18/10 03:07:
> On Thu, Sep 16, 2010 at 4:57 PM, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
>     Why was the ostream_abort() removed from the os::shutdown() path?
> 
>     In the existing code we have:
> 
>     VMError::report_and_die()
>      -> os::abort()
>        -> os::shutdown()
>           -> ostream_abort()
> 
> 
> It seems backward to me the the os-specific abort() calls ostream_abort(). 
> 
> Ostream_init() and ostream_init_log() are called from create_vm(), I 
> think it would be preferable to clean-up the ostreams at a similar level.

I don't see how you can given that you may need the streams right up 
until you actually abort the process, and that is done down in the 
depths of the os::abort/shutdown code at the end of the error path. 
Normal VM termination is a different matter and ostream_exit() is used 
for that purpose.

>     and you've moved ostream_abort() into report_and_die(), but there
>     are other exit paths that also call os::shutdown() and will no
>     longer call ostream_abort():
> 
>     vm_shutdown_during_initialization()
>     -> vm_shutdown()
>        -> os::shutdown()
> 
> 
> Agreed that I missed vm_shutdown() in java.cpp.   I'd be happy to add a 
> call to ostream_abort() there.

I think this is the wrong place to "abort" the output streams. It only 
works, in my view, because the tty and gc streams don't actually get 
"aborted" just flushed. Otherwise I suspect that there might be use of 
those streams after the current call to ostream_abort().

> Are there other call sites to os:shutdown() that I've missed?  If so, 
> perhaps it is safer to leave the originals calls in os::abort() as I've 
> underestimated the complexity of the shutdown code.

I don't think you missed anything else, but I think this is the wrong 
way to fix it.

>     Also with this move you need to fix this comment in ostream.cpp:
> 
>     // ostream_abort() is called by os::abort() when VM is about to die.
>     void ostream_abort() {
> 
> True.
>  
> 
>     Why not just add explicit flush() calls where needed?
> 
> 
> Flushing is pretty much what ostream_abort() does.  The compilation log 
> flushing code is short but non-trivial.  I think it is best not 
> duplicate the it.

I would rather see distinct flushing and "aborting" methods for the 
streams. ostream_abort() happens to also need to perform flushing, but 
flushing need not lead to aborting.

David

> -- Chuck
> 
> 
>     David Holmes
> 
> 
>         Contributed-by: rasbold at google.com <mailto:rasbold at google.com>
> 
> 

From christian.thalinger at oracle.com  Mon Sep 20 05:18:23 2010
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 20 Sep 2010 14:18:23 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <41c46841-693e-4bed-ac89-29cff7867a50@default>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
Message-ID: <1284985103.14822.2285.camel@macbook>

On Thu, 2010-09-16 at 11:47 -0700, Staffan Larsen wrote:
> http://cr.openjdk.java.net/~sla/6981484/webrev.00/
> 
> Update the development launcher (gamma) to 
>   1) not require env.sh to be sourced before launching
>   2) not require the current working directory to be the build directory
>   3) exist on windows platforms as well
>   4) support launching a debugger with -gdb/-gud (linux) or -dbx (solaris)
> 
> A few notes about the implementation:
> - I did not change the current gamma launcher, but chose to add a new "frontend" to it called "fusion". This is a script that sets up the necessary environment. This was to avoid changing something that works.
> - The launcher should really share code across platforms instead of being in os/<os>/launcher, but I wanted to keep the changes small.
> - The launcher code for Windows is a copy of the launcher found in 6u22 with changes (#ifndef GAMMA)

Just two comments:

1. Using a hardcoded ARCH in the launcher.script doesn't seem to be very
useful.

2. Why did you choose the name fusion (just to be part of history and to
be able to answer future questions :-)?

-- Christian


From staffan.larsen at oracle.com  Mon Sep 20 06:25:00 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 20 Sep 2010 06:25:00 -0700 (PDT)
Subject: Review request 6981484: Update development launcher
In-Reply-To: <1284985103.14822.2285.camel@macbook>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default
	1284985103.14822.2285.camel@macbook>
Message-ID: <b439ebc0-ee0e-4e1a-813b-a006f68040c2@default>

Christian,

The hardcoded ARCH should of course not be there, but rather it needs to be replaced (at build time) with the LIBARCH value. Will fix. Well spotted.

Since this launcher is based on similar code in JRockit, I choose the name "fusion". "Gamma" was already taken :-)

Thanks,
/Staffan

-----Original Message-----
From: Christian Thalinger 
Sent: den 20 september 2010 2:18
To: Staffan Larsen
Cc: hotspot-dev at openjdk.java.net
Subject: Re: Review request 6981484: Update development launcher

On Thu, 2010-09-16 at 11:47 -0700, Staffan Larsen wrote:
> http://cr.openjdk.java.net/~sla/6981484/webrev.00/
> 
> Update the development launcher (gamma) to 
>   1) not require env.sh to be sourced before launching
>   2) not require the current working directory to be the build directory
>   3) exist on windows platforms as well
>   4) support launching a debugger with -gdb/-gud (linux) or -dbx (solaris)
> 
> A few notes about the implementation:
> - I did not change the current gamma launcher, but chose to add a new "frontend" to it called "fusion". This is a script that sets up the necessary environment. This was to avoid changing something that works.
> - The launcher should really share code across platforms instead of being in os/<os>/launcher, but I wanted to keep the changes small.
> - The launcher code for Windows is a copy of the launcher found in 6u22 with changes (#ifndef GAMMA)

Just two comments:

1. Using a hardcoded ARCH in the launcher.script doesn't seem to be very
useful.

2. Why did you choose the name fusion (just to be part of history and to
be able to answer future questions :-)?

-- Christian


From daniel.daugherty at oracle.com  Mon Sep 20 08:23:59 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 20 Sep 2010 09:23:59 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
	<4C969A6C.9060002@oracle.com>
	<17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>
Message-ID: <4C977C8F.1000702@oracle.com>

On 9/19/2010 5:49 PM, Kelly O'Hair wrote:
>
> On Sep 19, 2010, at 4:19 PM, Daniel D. Daugherty wrote:
>
>> I guess that three line comment before that block doesn't do
>> the job. :-(  Can you please suggest a change to the comment
>> to make it more clear.
>>
>
> Oh, ok, looking at it closer....  this particular make rule evaluation 
> characteristics is a bit unknown.
> I doubt many people will understand what is happening here.
> I guess I would have said something more to the point for the typical 
> person:
>   "The '$(shell rm)' instead of $(RM) here is critical due to the 
> foreach use in the rules."

I've rewritten the entire comment block. It should
be more clear now. Please let me know if you agree:

http://cr.openjdk.java.net/~dcubed/6985848-webrev/2/


>
>> The file lists are generated at variable expansion time so we
>> have to do the remove at variable expansion time also. The
>> round 0 fix for 6985848 did the remove as a part of rule
>> execution, but that's too late and causes the javac to fail.
>
> The fact that AGENT_FILES1 and AGENT_FILES2 contains wildcards. I'm 
> suspecting a simple:
> find $(AGENT_SRC_DIR) -type f -name \*.java > list
> would work just as well, assuming the agent sources in the repository 
> all need to be built.
> But I know you are just trying to fix one issue and not redesign the 
> sa makefiles.

Redesigning the SA makefiles is tempting, but definitely not
high on my priority list.


> Your change should work.

It made it through a test JPRT job over the weekend and I verified
that an incremental build did not rebuild sa-jdi.jar on my machine
here in Colorado.

Dan


>
> -kto
>
>>
>> Dan
>>
>>
>> On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
>>> Why are you using
>>>    $(shell rm -f -r ... )
>>> instead of
>>>   $(RM) -r ...
>>>
>>> ???
>>>
>>>
>>> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>>>
>>>> I messed up the rule expansion... :-(
>>>>
>>>> Here's another shot:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>>>
>>>> This time I added a comment so the subtle difference
>>>> between macro/variable expansion versus rule execution
>>>> is a little more clear. I hope...
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>>>>> always be rebuilt. I have a minor tweak that fixes that problem:
>>>>>
>>>>>  http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>>>
>>>>> Thanks to Coleen for spotting this issue!
>>>>>
>>>>> The folks on the "To" list were on the original review team
>>>>> for 6561870. I would like to hear from at least two of those
>>>>> folks on this tweak.
>>>>>
>>>>> Thanks, in advance, for the reviews!
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>>>> Here is the revised webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>>>
>>>>>> One reviewer will do, I think...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>>>> Can the agent list files go into $(GENERATED) instead of 
>>>>>>> $(TOPDIR)?  Otherwise this looks good.
>>>>>>>
>>>>>>> tom
>>>>>>>
>>>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>>>>> send out a webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>>>
>>>>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>>>>
>>>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>>>> changes correct?
>>>>>>>>
>>>>>>>> Thanks, in advance, for any reviews...
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>>>
>>>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>>>
>>>>>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>>>>> would ask...
>>>>>>>>>>>
>>>>>>>>>> Yeah, I also thought about this for Solaris and it should 
>>>>>>>>>> work there as
>>>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>>>
>>>>>>>>> Looks like Windows already uses a "make" construct instead of 
>>>>>>>>> running
>>>>>>>>> into the shell command line limitation:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>      @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>>>>>> $(SA_CLASSPATH) -so
>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>>>>>      @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>>>>>> $(SA_CLASSPATH) -so
>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>>>>>
>>>>>>>>> I also think this is an "nmake" Makefile instead of a GNU 
>>>>>>>>> Makefile.
>>>>>>>>> I think I'll look at applying the changes to the Solaris 
>>>>>>>>> Makefile and
>>>>>>>>> leave the Windows stuff alone :-)
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

From rasbold at google.com  Mon Sep 20 11:15:35 2010
From: rasbold at google.com (Chuck Rasbold)
Date: Mon, 20 Sep 2010 11:15:35 -0700
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <4C9703D2.9080701@oracle.com>
References: <4C924FFE.607@oracle.com> <4C92AED1.3010906@oracle.com>
	<AANLkTik_boQfAtzRX2aLA_NKs4yv4fevT1NUgRP0kQd9@mail.gmail.com>
	<4C9703D2.9080701@oracle.com>
Message-ID: <AANLkTikN+01VAj5aBKowddrimq=7mzWbr2e3sqxYSoru@mail.gmail.com>

On Sun, Sep 19, 2010 at 11:48 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Chuck Rasbold said the following on 09/18/10 03:07:
>
>  On Thu, Sep 16, 2010 at 4:57 PM, David Holmes <David.Holmes at oracle.com<mailto:
>> David.Holmes at oracle.com>> wrote:
>>    Why was the ostream_abort() removed from the os::shutdown() path?
>>
>>    In the existing code we have:
>>
>>    VMError::report_and_die()
>>     -> os::abort()
>>       -> os::shutdown()
>>          -> ostream_abort()
>>
>>
>> It seems backward to me the the os-specific abort() calls ostream_abort().
>>
>> Ostream_init() and ostream_init_log() are called from create_vm(), I think
>> it would be preferable to clean-up the ostreams at a similar level.
>>
>
> I don't see how you can given that you may need the streams right up until
> you actually abort the process, and that is done down in the depths of the
> os::abort/shutdown code at the end of the error path. Normal VM termination
> is a different matter and ostream_exit() is used for that purpose.
>
>
>     and you've moved ostream_abort() into report_and_die(), but there
>>    are other exit paths that also call os::shutdown() and will no
>>    longer call ostream_abort():
>>
>>    vm_shutdown_during_initialization()
>>    -> vm_shutdown()
>>       -> os::shutdown()
>>
>>
>> Agreed that I missed vm_shutdown() in java.cpp.   I'd be happy to add a
>> call to ostream_abort() there.
>>
>
> I think this is the wrong place to "abort" the output streams. It only
> works, in my view, because the tty and gc streams don't actually get
> "aborted" just flushed. Otherwise I suspect that there might be use of those
> streams after the current call to ostream_abort().
>
>
>  Are there other call sites to os:shutdown() that I've missed?  If so,
>> perhaps it is safer to leave the originals calls in os::abort() as I've
>> underestimated the complexity of the shutdown code.
>>
>
> I don't think you missed anything else, but I think this is the wrong way
> to fix it.
>
>
>     Also with this move you need to fix this comment in ostream.cpp:
>>
>>    // ostream_abort() is called by os::abort() when VM is about to die.
>>    void ostream_abort() {
>>
>> True.
>>
>>    Why not just add explicit flush() calls where needed?
>>
>>
>> Flushing is pretty much what ostream_abort() does.  The compilation log
>> flushing code is short but non-trivial.  I think it is best not duplicate
>> the it.
>>
>
> I would rather see distinct flushing and "aborting" methods for the
> streams. ostream_abort() happens to also need to perform flushing, but
> flushing need not lead to aborting.
>

The "aborting" that ostream_abort() does is to flush and merge the
LogCompilation files.  That behavior is what we desire before OnError
commands are processed.

I could factor out an ostream_flush() function, but ithere's no place we'd
want to call it.

So is this OK?

http://cr.openjdk.java.net/~rasbold/6985422/webrev.00

-- Chuck


> David
>
>  -- Chuck
>>
>>
>>    David Holmes
>>
>>
>>        Contributed-by: rasbold at google.com <mailto:rasbold at google.com>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100920/895c286a/attachment.html 

From tom.rodriguez at oracle.com  Mon Sep 20 13:11:05 2010
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 20 Sep 2010 13:11:05 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C977C8F.1000702@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
	<4C969A6C.9060002@oracle.com>
	<17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>
	<4C977C8F.1000702@oracle.com>
Message-ID: <179C1DCB-90B1-42F2-9B79-0B79BD6E59F5@oracle.com>

Looks fine.

tom

On Sep 20, 2010, at 8:23 AM, Daniel D. Daugherty wrote:

> On 9/19/2010 5:49 PM, Kelly O'Hair wrote:
>> 
>> On Sep 19, 2010, at 4:19 PM, Daniel D. Daugherty wrote:
>> 
>>> I guess that three line comment before that block doesn't do
>>> the job. :-(  Can you please suggest a change to the comment
>>> to make it more clear.
>>> 
>> 
>> Oh, ok, looking at it closer....  this particular make rule evaluation characteristics is a bit unknown.
>> I doubt many people will understand what is happening here.
>> I guess I would have said something more to the point for the typical person:
>>  "The '$(shell rm)' instead of $(RM) here is critical due to the foreach use in the rules."
> 
> I've rewritten the entire comment block. It should
> be more clear now. Please let me know if you agree:
> 
> http://cr.openjdk.java.net/~dcubed/6985848-webrev/2/
> 
> 
>> 
>>> The file lists are generated at variable expansion time so we
>>> have to do the remove at variable expansion time also. The
>>> round 0 fix for 6985848 did the remove as a part of rule
>>> execution, but that's too late and causes the javac to fail.
>> 
>> The fact that AGENT_FILES1 and AGENT_FILES2 contains wildcards. I'm suspecting a simple:
>> find $(AGENT_SRC_DIR) -type f -name \*.java > list
>> would work just as well, assuming the agent sources in the repository all need to be built.
>> But I know you are just trying to fix one issue and not redesign the sa makefiles.
> 
> Redesigning the SA makefiles is tempting, but definitely not
> high on my priority list.
> 
> 
>> Your change should work.
> 
> It made it through a test JPRT job over the weekend and I verified
> that an incremental build did not rebuild sa-jdi.jar on my machine
> here in Colorado.
> 
> Dan
> 
> 
>> 
>> -kto
>> 
>>> 
>>> Dan
>>> 
>>> 
>>> On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
>>>> Why are you using
>>>>   $(shell rm -f -r ... )
>>>> instead of
>>>>  $(RM) -r ...
>>>> 
>>>> ???
>>>> 
>>>> 
>>>> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>>>> 
>>>>> I messed up the rule expansion... :-(
>>>>> 
>>>>> Here's another shot:
>>>>> 
>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>>>> 
>>>>> This time I added a comment so the subtle difference
>>>>> between macro/variable expansion versus rule execution
>>>>> is a little more clear. I hope...
>>>>> 
>>>>> Dan
>>>>> 
>>>>> 
>>>>> 
>>>>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>> 
>>>>>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>>>>>> always be rebuilt. I have a minor tweak that fixes that problem:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>>>> 
>>>>>> Thanks to Coleen for spotting this issue!
>>>>>> 
>>>>>> The folks on the "To" list were on the original review team
>>>>>> for 6561870. I would like to hear from at least two of those
>>>>>> folks on this tweak.
>>>>>> 
>>>>>> Thanks, in advance, for the reviews!
>>>>>> 
>>>>>> Dan
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>>>>> Here is the revised webrev:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>>>> 
>>>>>>> One reviewer will do, I think...
>>>>>>> 
>>>>>>> Dan
>>>>>>> 
>>>>>>> 
>>>>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>>>>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>>>>>>>> 
>>>>>>>> tom
>>>>>>>> 
>>>>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>>>>>> send out a webrev:
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>>>> 
>>>>>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>>>>> 
>>>>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>>>>> changes correct?
>>>>>>>>> 
>>>>>>>>> Thanks, in advance, for any reviews...
>>>>>>>>> 
>>>>>>>>> Dan
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>>>> 
>>>>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>>>> 
>>>>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>>>> 
>>>>>>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>>>>>> would ask...
>>>>>>>>>>>> 
>>>>>>>>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>>>> 
>>>>>>>>>> Looks like Windows already uses a "make" construct instead of running
>>>>>>>>>> into the shell command line limitation:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>>>>>> 
>>>>>>>>>> <snip>
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>     @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>>>>>>     @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>>>>>> 
>>>>>>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>>>>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>>>>>>>> leave the Windows stuff alone :-)
>>>>>>>>>> 
>>>>>>>>>> Dan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 


From daniel.daugherty at oracle.com  Mon Sep 20 13:19:43 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 20 Sep 2010 14:19:43 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <179C1DCB-90B1-42F2-9B79-0B79BD6E59F5@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
	<4C969A6C.9060002@oracle.com>
	<17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>
	<4C977C8F.1000702@oracle.com>
	<179C1DCB-90B1-42F2-9B79-0B79BD6E59F5@oracle.com>
Message-ID: <4C97C1DF.4090804@oracle.com>

Thanks for the review! And thanks for reviewing multiple rounds
of _both_ fixes... Did I mention how I hate Makefile changes
recently? :-)

Dan


On 9/20/2010 2:11 PM, Tom Rodriguez wrote:
> Looks fine.
>
> tom
>
> On Sep 20, 2010, at 8:23 AM, Daniel D. Daugherty wrote:
>
>   
>> On 9/19/2010 5:49 PM, Kelly O'Hair wrote:
>>     
>>> On Sep 19, 2010, at 4:19 PM, Daniel D. Daugherty wrote:
>>>
>>>       
>>>> I guess that three line comment before that block doesn't do
>>>> the job. :-(  Can you please suggest a change to the comment
>>>> to make it more clear.
>>>>
>>>>         
>>> Oh, ok, looking at it closer....  this particular make rule evaluation characteristics is a bit unknown.
>>> I doubt many people will understand what is happening here.
>>> I guess I would have said something more to the point for the typical person:
>>>  "The '$(shell rm)' instead of $(RM) here is critical due to the foreach use in the rules."
>>>       
>> I've rewritten the entire comment block. It should
>> be more clear now. Please let me know if you agree:
>>
>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/2/
>>
>>
>>     
>>>> The file lists are generated at variable expansion time so we
>>>> have to do the remove at variable expansion time also. The
>>>> round 0 fix for 6985848 did the remove as a part of rule
>>>> execution, but that's too late and causes the javac to fail.
>>>>         
>>> The fact that AGENT_FILES1 and AGENT_FILES2 contains wildcards. I'm suspecting a simple:
>>> find $(AGENT_SRC_DIR) -type f -name \*.java > list
>>> would work just as well, assuming the agent sources in the repository all need to be built.
>>> But I know you are just trying to fix one issue and not redesign the sa makefiles.
>>>       
>> Redesigning the SA makefiles is tempting, but definitely not
>> high on my priority list.
>>
>>
>>     
>>> Your change should work.
>>>       
>> It made it through a test JPRT job over the weekend and I verified
>> that an incremental build did not rebuild sa-jdi.jar on my machine
>> here in Colorado.
>>
>> Dan
>>
>>
>>     
>>> -kto
>>>
>>>       
>>>> Dan
>>>>
>>>>
>>>> On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
>>>>         
>>>>> Why are you using
>>>>>   $(shell rm -f -r ... )
>>>>> instead of
>>>>>  $(RM) -r ...
>>>>>
>>>>> ???
>>>>>
>>>>>
>>>>> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>>>>>
>>>>>           
>>>>>> I messed up the rule expansion... :-(
>>>>>>
>>>>>> Here's another shot:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>>>>>
>>>>>> This time I added a comment so the subtle difference
>>>>>> between macro/variable expansion versus rule execution
>>>>>> is a little more clear. I hope...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>>>>>             
>>>>>>> Greetings,
>>>>>>>
>>>>>>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>>>>>>> always be rebuilt. I have a minor tweak that fixes that problem:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>>>>>
>>>>>>> Thanks to Coleen for spotting this issue!
>>>>>>>
>>>>>>> The folks on the "To" list were on the original review team
>>>>>>> for 6561870. I would like to hear from at least two of those
>>>>>>> folks on this tweak.
>>>>>>>
>>>>>>> Thanks, in advance, for the reviews!
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>>>>>               
>>>>>>>> Here is the revised webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>>>>>
>>>>>>>> One reviewer will do, I think...
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>>>>>                 
>>>>>>>>> Can the agent list files go into $(GENERATED) instead of $(TOPDIR)?  Otherwise this looks good.
>>>>>>>>>
>>>>>>>>> tom
>>>>>>>>>
>>>>>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>>>>>>> send out a webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>>>>>
>>>>>>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>>>>>>
>>>>>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>>>>>> changes correct?
>>>>>>>>>>
>>>>>>>>>> Thanks, in advance, for any reviews...
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there a reason to not apply these changes to the solaris and
>>>>>>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>>>>>>> would ask...
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>> Yeah, I also thought about this for Solaris and it should work there as
>>>>>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>> Looks like Windows already uses a "make" construct instead of running
>>>>>>>>>>> into the shell command line limitation:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\)
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>> <snip>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>>     @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>>>>>>>     @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $(SA_CLASSPATH) -so
>>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>> I also think this is an "nmake" Makefile instead of a GNU Makefile.
>>>>>>>>>>> I think I'll look at applying the changes to the Solaris Makefile and
>>>>>>>>>>> leave the Windows stuff alone :-)
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>
>>>>>>>>>                   
>
>   

From kelly.ohair at oracle.com  Mon Sep 20 13:21:54 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 20 Sep 2010 13:21:54 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C977C8F.1000702@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
	<4C969A6C.9060002@oracle.com>
	<17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>
	<4C977C8F.1000702@oracle.com>
Message-ID: <E271A5B6-E3B0-4AA4-9F38-65310273450C@oracle.com>

Looks good.

-kto

On Sep 20, 2010, at 8:23 AM, Daniel D. Daugherty wrote:

> On 9/19/2010 5:49 PM, Kelly O'Hair wrote:
>>
>> On Sep 19, 2010, at 4:19 PM, Daniel D. Daugherty wrote:
>>
>>> I guess that three line comment before that block doesn't do
>>> the job. :-(  Can you please suggest a change to the comment
>>> to make it more clear.
>>>
>>
>> Oh, ok, looking at it closer....  this particular make rule  
>> evaluation characteristics is a bit unknown.
>> I doubt many people will understand what is happening here.
>> I guess I would have said something more to the point for the  
>> typical person:
>>  "The '$(shell rm)' instead of $(RM) here is critical due to the  
>> foreach use in the rules."
>
> I've rewritten the entire comment block. It should
> be more clear now. Please let me know if you agree:
>
> http://cr.openjdk.java.net/~dcubed/6985848-webrev/2/
>
>
>>
>>> The file lists are generated at variable expansion time so we
>>> have to do the remove at variable expansion time also. The
>>> round 0 fix for 6985848 did the remove as a part of rule
>>> execution, but that's too late and causes the javac to fail.
>>
>> The fact that AGENT_FILES1 and AGENT_FILES2 contains wildcards. I'm  
>> suspecting a simple:
>> find $(AGENT_SRC_DIR) -type f -name \*.java > list
>> would work just as well, assuming the agent sources in the  
>> repository all need to be built.
>> But I know you are just trying to fix one issue and not redesign  
>> the sa makefiles.
>
> Redesigning the SA makefiles is tempting, but definitely not
> high on my priority list.
>
>
>> Your change should work.
>
> It made it through a test JPRT job over the weekend and I verified
> that an incremental build did not rebuild sa-jdi.jar on my machine
> here in Colorado.
>
> Dan
>
>
>>
>> -kto
>>
>>>
>>> Dan
>>>
>>>
>>> On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
>>>> Why are you using
>>>>   $(shell rm -f -r ... )
>>>> instead of
>>>>  $(RM) -r ...
>>>>
>>>> ???
>>>>
>>>>
>>>> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>>>>
>>>>> I messed up the rule expansion... :-(
>>>>>
>>>>> Here's another shot:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>>>>
>>>>> This time I added a comment so the subtle difference
>>>>> between macro/variable expansion versus rule execution
>>>>> is a little more clear. I hope...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>>>>>> always be rebuilt. I have a minor tweak that fixes that problem:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>>>>
>>>>>> Thanks to Coleen for spotting this issue!
>>>>>>
>>>>>> The folks on the "To" list were on the original review team
>>>>>> for 6561870. I would like to hear from at least two of those
>>>>>> folks on this tweak.
>>>>>>
>>>>>> Thanks, in advance, for the reviews!
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>>>>> Here is the revised webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>>>>
>>>>>>> One reviewer will do, I think...
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>>>>> Can the agent list files go into $(GENERATED) instead of $ 
>>>>>>>> (TOPDIR)?  Otherwise this looks good.
>>>>>>>>
>>>>>>>> tom
>>>>>>>>
>>>>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> I'm finally getting back to this thread. Since I'm also  
>>>>>>>>> applying
>>>>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I  
>>>>>>>>> would
>>>>>>>>> send out a webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>>>>
>>>>>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>>>>>
>>>>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>>>>> changes correct?
>>>>>>>>>
>>>>>>>>> Thanks, in advance, for any reviews...
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>>>>
>>>>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty  
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a reason to not apply these changes to the  
>>>>>>>>>>>> solaris and
>>>>>>>>>>>> windows versions also? I haven't looked yet, but I  
>>>>>>>>>>>> figured I
>>>>>>>>>>>> would ask...
>>>>>>>>>>>>
>>>>>>>>>>> Yeah, I also thought about this for Solaris and it should  
>>>>>>>>>>> work there as
>>>>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>>>>
>>>>>>>>>> Looks like Windows already uses a "make" construct instead  
>>>>>>>>>> of running
>>>>>>>>>> into the shell command line limitation:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $ 
>>>>>>>>>>> (AGENT_FILES2:/=\)
>>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>     @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>>>>>> (SA_CLASSPATH) -so
>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $ 
>>>>>>>>>>> (AGENT_FILES1:/=\)
>>>>>>>>>>>     @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>>>>>> (SA_CLASSPATH) -so
>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $ 
>>>>>>>>>>> (AGENT_FILES2:/=\)
>>>>>>>>>>>
>>>>>>>>>> I also think this is an "nmake" Makefile instead of a GNU  
>>>>>>>>>> Makefile.
>>>>>>>>>> I think I'll look at applying the changes to the Solaris  
>>>>>>>>>> Makefile and
>>>>>>>>>> leave the Windows stuff alone :-)
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>


From kelly.ohair at oracle.com  Mon Sep 20 13:25:40 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 20 Sep 2010 13:25:40 -0700
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C97C1DF.4090804@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>
	<4C93D02A.4000009@oracle.com> <4C9444DF.5050807@oracle.com>
	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>
	<4C969A6C.9060002@oracle.com>
	<17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>
	<4C977C8F.1000702@oracle.com>
	<179C1DCB-90B1-42F2-9B79-0B79BD6E59F5@oracle.com>
	<4C97C1DF.4090804@oracle.com>
Message-ID: <8ACE0A23-DC55-4C8E-BC3A-28034691EE55@oracle.com>


Darn, and I was going to nominate you to complete re-write all the  
hotspot makefiles.   ;^>

-kto

On Sep 20, 2010, at 1:19 PM, Daniel D. Daugherty wrote:

> Thanks for the review! And thanks for reviewing multiple rounds
> of _both_ fixes... Did I mention how I hate Makefile changes
> recently? :-)
>
> Dan
>
>
> On 9/20/2010 2:11 PM, Tom Rodriguez wrote:
>> Looks fine.
>>
>> tom
>>
>> On Sep 20, 2010, at 8:23 AM, Daniel D. Daugherty wrote:
>>
>>
>>> On 9/19/2010 5:49 PM, Kelly O'Hair wrote:
>>>
>>>> On Sep 19, 2010, at 4:19 PM, Daniel D. Daugherty wrote:
>>>>
>>>>
>>>>> I guess that three line comment before that block doesn't do
>>>>> the job. :-(  Can you please suggest a change to the comment
>>>>> to make it more clear.
>>>>>
>>>>>
>>>> Oh, ok, looking at it closer....  this particular make rule  
>>>> evaluation characteristics is a bit unknown.
>>>> I doubt many people will understand what is happening here.
>>>> I guess I would have said something more to the point for the  
>>>> typical person:
>>>> "The '$(shell rm)' instead of $(RM) here is critical due to the  
>>>> foreach use in the rules."
>>>>
>>> I've rewritten the entire comment block. It should
>>> be more clear now. Please let me know if you agree:
>>>
>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/2/
>>>
>>>
>>>
>>>>> The file lists are generated at variable expansion time so we
>>>>> have to do the remove at variable expansion time also. The
>>>>> round 0 fix for 6985848 did the remove as a part of rule
>>>>> execution, but that's too late and causes the javac to fail.
>>>>>
>>>> The fact that AGENT_FILES1 and AGENT_FILES2 contains wildcards.  
>>>> I'm suspecting a simple:
>>>> find $(AGENT_SRC_DIR) -type f -name \*.java > list
>>>> would work just as well, assuming the agent sources in the  
>>>> repository all need to be built.
>>>> But I know you are just trying to fix one issue and not redesign  
>>>> the sa makefiles.
>>>>
>>> Redesigning the SA makefiles is tempting, but definitely not
>>> high on my priority list.
>>>
>>>
>>>
>>>> Your change should work.
>>>>
>>> It made it through a test JPRT job over the weekend and I verified
>>> that an incremental build did not rebuild sa-jdi.jar on my machine
>>> here in Colorado.
>>>
>>> Dan
>>>
>>>
>>>
>>>> -kto
>>>>
>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
>>>>>
>>>>>> Why are you using
>>>>>>  $(shell rm -f -r ... )
>>>>>> instead of
>>>>>> $(RM) -r ...
>>>>>>
>>>>>> ???
>>>>>>
>>>>>>
>>>>>> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>>>>>>
>>>>>>
>>>>>>> I messed up the rule expansion... :-(
>>>>>>>
>>>>>>> Here's another shot:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>>>>>>
>>>>>>> This time I added a comment so the subtle difference
>>>>>>> between macro/variable expansion versus rule execution
>>>>>>> is a little more clear. I hope...
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>>>>>>
>>>>>>>> Greetings,
>>>>>>>>
>>>>>>>> The fix for this bug (6561870) has caused the sa-jdi.jar file  
>>>>>>>> to
>>>>>>>> always be rebuilt. I have a minor tweak that fixes that  
>>>>>>>> problem:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>>>>>>
>>>>>>>> Thanks to Coleen for spotting this issue!
>>>>>>>>
>>>>>>>> The folks on the "To" list were on the original review team
>>>>>>>> for 6561870. I would like to hear from at least two of those
>>>>>>>> folks on this tweak.
>>>>>>>>
>>>>>>>> Thanks, in advance, for the reviews!
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>>>>>>
>>>>>>>>> Here is the revised webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>>>>>>
>>>>>>>>> One reviewer will do, I think...
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>>>>>>
>>>>>>>>>> Can the agent list files go into $(GENERATED) instead of $ 
>>>>>>>>>> (TOPDIR)?  Otherwise this looks good.
>>>>>>>>>>
>>>>>>>>>> tom
>>>>>>>>>>
>>>>>>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I'm finally getting back to this thread. Since I'm also  
>>>>>>>>>>> applying
>>>>>>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I  
>>>>>>>>>>> would
>>>>>>>>>>> send out a webrev:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>>>>>>
>>>>>>>>>>> Kelly and Christian, can I get re-reviews from the two of  
>>>>>>>>>>> you?
>>>>>>>>>>>
>>>>>>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>>>>>>> changes correct?
>>>>>>>>>>>
>>>>>>>>>>> Thanks, in advance, for any reviews...
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty  
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there a reason to not apply these changes to the  
>>>>>>>>>>>>>> solaris and
>>>>>>>>>>>>>> windows versions also? I haven't looked yet, but I  
>>>>>>>>>>>>>> figured I
>>>>>>>>>>>>>> would ask...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Yeah, I also thought about this for Solaris and it  
>>>>>>>>>>>>> should work there as
>>>>>>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> Looks like Windows already uses a "make" construct  
>>>>>>>>>>>> instead of running
>>>>>>>>>>>> into the shell command line limitation:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $ 
>>>>>>>>>>>>> (AGENT_FILES2:/=\)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> <snip>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>    @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>>>>>>>> (SA_CLASSPATH) -so
>>>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $ 
>>>>>>>>>>>>> (AGENT_FILES1:/=\)
>>>>>>>>>>>>>    @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath $ 
>>>>>>>>>>>>> (SA_CLASSPATH) -so
>>>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $ 
>>>>>>>>>>>>> (AGENT_FILES2:/=\)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> I also think this is an "nmake" Makefile instead of a GNU  
>>>>>>>>>>>> Makefile.
>>>>>>>>>>>> I think I'll look at applying the changes to the Solaris  
>>>>>>>>>>>> Makefile and
>>>>>>>>>>>> leave the Windows stuff alone :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
>>


From David.Holmes at oracle.com  Mon Sep 20 16:58:35 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 21 Sep 2010 09:58:35 +1000
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <AANLkTikN+01VAj5aBKowddrimq=7mzWbr2e3sqxYSoru@mail.gmail.com>
References: <4C924FFE.607@oracle.com>	<4C92AED1.3010906@oracle.com>	<AANLkTik_boQfAtzRX2aLA_NKs4yv4fevT1NUgRP0kQd9@mail.gmail.com>	<4C9703D2.9080701@oracle.com>
	<AANLkTikN+01VAj5aBKowddrimq=7mzWbr2e3sqxYSoru@mail.gmail.com>
Message-ID: <4C97F52B.7070608@oracle.com>

Chuck Rasbold said the following on 09/21/10 04:15:
> The "aborting" that ostream_abort() does is to flush and merge the 
> LogCompilation files.  That behavior is what we desire before OnError 
> commands are processed.

flush I can understand.

> I could factor out an ostream_flush() function, but ithere's no place 
> we'd want to call it.
> 
> So is this OK?
> 
> http://cr.openjdk.java.net/~rasbold/6985422/webrev.00

Yes, in that calling ostream_abort() a second time in os::shutdown will 
be a no-op.

My only lingering concern is that while one thread is reporting this 
fatal error the rest of the VM continues to execute, and those other 
threads might encounter a stream/log-file that has now been closed. I 
don't know if this would be handled gracefully or whether we care one 
way or the other. We have the same issue with the ostream_abort in 
os::shutdown but the window between closing the files and blowing away 
the process is very small. In this case your onError commands could take 
an indeterminate amount of time during which the rest of the VM 
continues to execute.

David

> -- Chuck

From staffan.larsen at oracle.com  Tue Sep 21 05:51:25 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 21 Sep 2010 05:51:25 -0700 (PDT)
Subject: Review request 6981484: Update development launcher
In-Reply-To: <1284985103.14822.2285.camel@macbook>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default
	1284985103.14822.2285.camel@macbook>
Message-ID: <50ee9673-7a05-48ce-954a-3541eca08e2a@default>

http://cr.openjdk.java.net/~sla/6981484/webrev.01/

Here is an updated webrev. I now "preprocess" the launcher script with sed to insert the correct ARCH.

Thanks,
/Staffan

-----Original Message-----
From: Christian Thalinger 
Sent: den 20 september 2010 2:18
To: Staffan Larsen
Cc: hotspot-dev at openjdk.java.net
Subject: Re: Review request 6981484: Update development launcher

On Thu, 2010-09-16 at 11:47 -0700, Staffan Larsen wrote:
> http://cr.openjdk.java.net/~sla/6981484/webrev.00/
> 
> Update the development launcher (gamma) to 
>   1) not require env.sh to be sourced before launching
>   2) not require the current working directory to be the build directory
>   3) exist on windows platforms as well
>   4) support launching a debugger with -gdb/-gud (linux) or -dbx (solaris)
> 
> A few notes about the implementation:
> - I did not change the current gamma launcher, but chose to add a new "frontend" to it called "fusion". This is a script that sets up the necessary environment. This was to avoid changing something that works.
> - The launcher should really share code across platforms instead of being in os/<os>/launcher, but I wanted to keep the changes small.
> - The launcher code for Windows is a copy of the launcher found in 6u22 with changes (#ifndef GAMMA)

Just two comments:

1. Using a hardcoded ARCH in the launcher.script doesn't seem to be very
useful.

2. Why did you choose the name fusion (just to be part of history and to
be able to answer future questions :-)?

-- Christian


From daniel.daugherty at oracle.com  Tue Sep 21 06:57:18 2010
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 21 Sep 2010 07:57:18 -0600
Subject: [patch] fix hotspot build with small SC_ARG_MAX
In-Reply-To: <4C977C8F.1000702@oracle.com>
References: <4C736DDD.9040009@ubuntu.com>		<ABD01B03-2021-479E-A8CF-9BA286E90073@oracle.com>		<4C7516F2.3090605@oracle.com>	<1282742800.28481.20.camel@macbook>		<4C751B5C.4020500@oracle.com>	<4C753E38.8070208@oracle.com>	<1282752683.32311.4.camel@macbook>	<4C75434B.7080307@oracle.com>	<4C7E93A3.1030401@oracle.com>	<D953DBB8-1E46-4E67-BECA-1A5AF4429746@oracle.com>	<4C818EEB.7030107@oracle.com>	<4C93D02A.4000009@oracle.com>
	<4C9444DF.5050807@oracle.com>	<1FF6E945-3ADE-4386-8EDA-D4409C41A284@oracle.com>	<4C969A6C.9060002@oracle.com>	<17156652-EBFF-48BE-9D10-5EEC4ACCD272@oracle.com>
	<4C977C8F.1000702@oracle.com>
Message-ID: <4C98B9BE.3000907@oracle.com>

Greetings,

This is either in the "you learn something new everyday" category
or it's in the "will this Makefile pain ever stop" category!

Yesterday's comment only change in sa.make didn't pass JPRT.
When this line is indented with a tab:

    # using '$(shell rm ...' instead of using the more traditional

gnumake tries to execute the shell command. Good thing I didn't have
the trailing ')' and good thing I didn't name a real file in there.

Just for the completeness of the record:

   http://cr.openjdk.java.net/~dcubed/6985848-webrev/3/

I exdented (unindented?) the entire new comment block. This
version of the fix passes my local full build and incremental
build on Solaris X86 and I expect it to pass JPRT.

Kelly, I'll be happy if I never look at another Makefile for
a long, long time...

Dan



On 9/20/2010 9:23 AM, Daniel D. Daugherty wrote:
> On 9/19/2010 5:49 PM, Kelly O'Hair wrote:
>>
>> On Sep 19, 2010, at 4:19 PM, Daniel D. Daugherty wrote:
>>
>>> I guess that three line comment before that block doesn't do
>>> the job. :-(  Can you please suggest a change to the comment
>>> to make it more clear.
>>>
>>
>> Oh, ok, looking at it closer....  this particular make rule 
>> evaluation characteristics is a bit unknown.
>> I doubt many people will understand what is happening here.
>> I guess I would have said something more to the point for the typical 
>> person:
>>   "The '$(shell rm)' instead of $(RM) here is critical due to the 
>> foreach use in the rules."
>
> I've rewritten the entire comment block. It should
> be more clear now. Please let me know if you agree:
>
> http://cr.openjdk.java.net/~dcubed/6985848-webrev/2/
>
>
>>
>>> The file lists are generated at variable expansion time so we
>>> have to do the remove at variable expansion time also. The
>>> round 0 fix for 6985848 did the remove as a part of rule
>>> execution, but that's too late and causes the javac to fail.
>>
>> The fact that AGENT_FILES1 and AGENT_FILES2 contains wildcards. I'm 
>> suspecting a simple:
>> find $(AGENT_SRC_DIR) -type f -name \*.java > list
>> would work just as well, assuming the agent sources in the repository 
>> all need to be built.
>> But I know you are just trying to fix one issue and not redesign the 
>> sa makefiles.
>
> Redesigning the SA makefiles is tempting, but definitely not
> high on my priority list.
>
>
>> Your change should work.
>
> It made it through a test JPRT job over the weekend and I verified
> that an incremental build did not rebuild sa-jdi.jar on my machine
> here in Colorado.
>
> Dan
>
>
>>
>> -kto
>>
>>>
>>> Dan
>>>
>>>
>>> On 9/19/2010 2:08 PM, Kelly O'Hair wrote:
>>>> Why are you using
>>>>    $(shell rm -f -r ... )
>>>> instead of
>>>>   $(RM) -r ...
>>>>
>>>> ???
>>>>
>>>>
>>>> On Sep 17, 2010, at 9:49 PM, Daniel D. Daugherty wrote:
>>>>
>>>>> I messed up the rule expansion... :-(
>>>>>
>>>>> Here's another shot:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/6985848-webrev/1/
>>>>>
>>>>> This time I added a comment so the subtle difference
>>>>> between macro/variable expansion versus rule execution
>>>>> is a little more clear. I hope...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>> On 9/17/2010 2:31 PM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> The fix for this bug (6561870) has caused the sa-jdi.jar file to
>>>>>> always be rebuilt. I have a minor tweak that fixes that problem:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~dcubed/6985848-webrev/0/
>>>>>>
>>>>>> Thanks to Coleen for spotting this issue!
>>>>>>
>>>>>> The folks on the "To" list were on the original review team
>>>>>> for 6561870. I would like to hear from at least two of those
>>>>>> folks on this tweak.
>>>>>>
>>>>>> Thanks, in advance, for the reviews!
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/3/2010 6:12 PM, Daniel D. Daugherty wrote:
>>>>>>> Here is the revised webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/1/
>>>>>>>
>>>>>>> One reviewer will do, I think...
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 9/1/2010 12:17 PM, Tom Rodriguez wrote:
>>>>>>>> Can the agent list files go into $(GENERATED) instead of 
>>>>>>>> $(TOPDIR)?  Otherwise this looks good.
>>>>>>>>
>>>>>>>> tom
>>>>>>>>
>>>>>>>> On Sep 1, 2010, at 10:55 AM, Daniel D. Daugherty wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> I'm finally getting back to this thread. Since I'm also applying
>>>>>>>>> Matthias' changes to the Solaris sa.makefile, I figured I would
>>>>>>>>> send out a webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/6561870-webrev/0/
>>>>>>>>>
>>>>>>>>> Kelly and Christian, can I get re-reviews from the two of you?
>>>>>>>>>
>>>>>>>>> Matthias, can you verify that I got the Solaris port of your
>>>>>>>>> changes correct?
>>>>>>>>>
>>>>>>>>> Thanks, in advance, for any reviews...
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/25/2010 10:22 AM, Daniel D. Daugherty wrote:
>>>>>>>>>
>>>>>>>>>> On 8/25/2010 10:11 AM, Christian Thalinger wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the reviews Kelly and Christian.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a reason to not apply these changes to the solaris 
>>>>>>>>>>>> and
>>>>>>>>>>>> windows versions also? I haven't looked yet, but I figured I
>>>>>>>>>>>> would ask...
>>>>>>>>>>>>
>>>>>>>>>>> Yeah, I also thought about this for Solaris and it should 
>>>>>>>>>>> work there as
>>>>>>>>>>> on Linux.  Don't know about Windows, though.
>>>>>>>>>>>
>>>>>>>>>> Looks like Windows already uses a "make" construct instead of 
>>>>>>>>>> running
>>>>>>>>>> into the shell command line limitation:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) 
>>>>>>>>>>> $(AGENT_FILES2:/=\)
>>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>      @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>>>>>>> $(SA_CLASSPATH) -so
>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\)
>>>>>>>>>>>      @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath 
>>>>>>>>>>> $(SA_CLASSPATH) -so
>>>>>>>>>>> urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\)
>>>>>>>>>>>
>>>>>>>>>> I also think this is an "nmake" Makefile instead of a GNU 
>>>>>>>>>> Makefile.
>>>>>>>>>> I think I'll look at applying the changes to the Solaris 
>>>>>>>>>> Makefile and
>>>>>>>>>> leave the Windows stuff alone :-)
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

From christian.thalinger at oracle.com  Tue Sep 21 09:49:18 2010
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 21 Sep 2010 18:49:18 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <50ee9673-7a05-48ce-954a-3541eca08e2a@default>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default
	1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
Message-ID: <1285087758.14822.3018.camel@macbook>

On Tue, 2010-09-21 at 05:51 -0700, Staffan Larsen wrote:
> http://cr.openjdk.java.net/~sla/6981484/webrev.01/
> 
> Here is an updated webrev. I now "preprocess" the launcher script with
> sed to insert the correct ARCH.

Some files miss a copyright header and others need to be updated.
Otherwise this looks good.

-- Christian


From staffan.larsen at oracle.com  Wed Sep 22 05:23:03 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Sep 2010 05:23:03 -0700 (PDT)
Subject: Review request 6981484: Update development launcher
In-Reply-To: <1285087758.14822.3018.camel@macbook>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default
	1285087758.14822.3018.camel@macbook>
Message-ID: <629026fb-5d9f-4760-a2c4-fb945998f0c1@default>

Thanks Christian - I obviously have some things to learn as a new committer - didn't think about the copyrights :-)


http://cr.openjdk.java.net/~sla/6981484/webrev.02/

Now with updated copyrights.

Also removed changes to LD_LIBRARY_PATH in env.(sh|csh) since these were unrelated to the new launcher.

Thanks,
/Staffan


-----Original Message-----
From: Christian Thalinger 
Sent: den 21 september 2010 6:49
To: Staffan Larsen
Cc: hotspot-dev at openjdk.java.net
Subject: RE: Review request 6981484: Update development launcher

On Tue, 2010-09-21 at 05:51 -0700, Staffan Larsen wrote:
> http://cr.openjdk.java.net/~sla/6981484/webrev.01/
> 
> Here is an updated webrev. I now "preprocess" the launcher script with
> sed to insert the correct ARCH.

Some files miss a copyright header and others need to be updated.
Otherwise this looks good.

-- Christian


From staffan.larsen at oracle.com  Wed Sep 22 05:30:03 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Sep 2010 05:30:03 -0700 (PDT)
Subject: Review request 6981484: Update development launcher
In-Reply-To: <4C99F6AC.2060400@oracle.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default
	1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default
	4C99F6AC.2060400@oracle.com>
Message-ID: <c1381e11-1239-4889-8320-2f48d40cc636@default>

Doh! Will fix :-)

-----Original Message-----
From: David Holmes 
Sent: den 22 september 2010 2:30
To: Staffan Larsen
Cc: Christian Thalinger; hotspot-dev at openjdk.java.net
Subject: Re: Review request 6981484: Update development launcher

Hi Staffan,

Staffan Larsen said the following on 09/22/10 22:23:
> Thanks Christian - I obviously have some things to learn as a new committer - didn't think about the copyrights :-)
> 
> 
> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
> 
> Now with updated copyrights.

Oracle's copyright policy is to use first year and last year only eg:

Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.

David

> Also removed changes to LD_LIBRARY_PATH in env.(sh|csh) since these were unrelated to the new launcher.
> 
> Thanks,
> /Staffan
> 
> 
> -----Original Message-----
> From: Christian Thalinger 
> Sent: den 21 september 2010 6:49
> To: Staffan Larsen
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: Review request 6981484: Update development launcher
> 
> On Tue, 2010-09-21 at 05:51 -0700, Staffan Larsen wrote:
>> http://cr.openjdk.java.net/~sla/6981484/webrev.01/
>>
>> Here is an updated webrev. I now "preprocess" the launcher script with
>> sed to insert the correct ARCH.
> 
> Some files miss a copyright header and others need to be updated.
> Otherwise this looks good.
> 
> -- Christian
> 

From David.Holmes at oracle.com  Wed Sep 22 05:29:32 2010
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 22 Sep 2010 22:29:32 +1000
Subject: Review request 6981484: Update development launcher
In-Reply-To: <629026fb-5d9f-4760-a2c4-fb945998f0c1@default>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>	<1284985103.14822.2285.camel@macbook>	<50ee9673-7a05-48ce-954a-3541eca08e2a@default	1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default>
Message-ID: <4C99F6AC.2060400@oracle.com>

Hi Staffan,

Staffan Larsen said the following on 09/22/10 22:23:
> Thanks Christian - I obviously have some things to learn as a new committer - didn't think about the copyrights :-)
> 
> 
> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
> 
> Now with updated copyrights.

Oracle's copyright policy is to use first year and last year only eg:

Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.

David

> Also removed changes to LD_LIBRARY_PATH in env.(sh|csh) since these were unrelated to the new launcher.
> 
> Thanks,
> /Staffan
> 
> 
> -----Original Message-----
> From: Christian Thalinger 
> Sent: den 21 september 2010 6:49
> To: Staffan Larsen
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: Review request 6981484: Update development launcher
> 
> On Tue, 2010-09-21 at 05:51 -0700, Staffan Larsen wrote:
>> http://cr.openjdk.java.net/~sla/6981484/webrev.01/
>>
>> Here is an updated webrev. I now "preprocess" the launcher script with
>> sed to insert the correct ARCH.
> 
> Some files miss a copyright header and others need to be updated.
> Otherwise this looks good.
> 
> -- Christian
> 

From staffan.larsen at oracle.com  Wed Sep 22 05:38:23 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Sep 2010 05:38:23 -0700 (PDT)
Subject: Review request 6981484: Update development launcher
In-Reply-To: <1285159093.14822.3636.camel@macbook>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default
	1285159093.14822.3636.camel@macbook>
Message-ID: <3b7d727a-e930-4721-b064-1b539e7c9193@default>

Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/

Eventually, I'll get there...

Thanks,
/Staffan

-----Original Message-----
From: Christian Thalinger 
Sent: den 22 september 2010 2:38
To: Staffan Larsen
Cc: hotspot-dev at openjdk.java.net
Subject: RE: Review request 6981484: Update development launcher

On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
> Thanks Christian - I obviously have some things to learn as a new
> committer - didn't think about the copyrights :-)

Sure.  I was going the same route :-)

> 
> 
> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
> 
> Now with updated copyrights.

As David already said.

-- Christian


From christian.thalinger at oracle.com  Wed Sep 22 05:38:13 2010
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 22 Sep 2010 14:38:13 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <629026fb-5d9f-4760-a2c4-fb945998f0c1@default>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default
	1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default>
Message-ID: <1285159093.14822.3636.camel@macbook>

On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
> Thanks Christian - I obviously have some things to learn as a new
> committer - didn't think about the copyrights :-)

Sure.  I was going the same route :-)

> 
> 
> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
> 
> Now with updated copyrights.

As David already said.

-- Christian


From christian.thalinger at oracle.com  Wed Sep 22 05:48:13 2010
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 22 Sep 2010 14:48:13 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <3b7d727a-e930-4721-b064-1b539e7c9193@default>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default
	1285159093.14822.3636.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
Message-ID: <1285159693.14822.3647.camel@macbook>

On Wed, 2010-09-22 at 05:38 -0700, Staffan Larsen wrote:
> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
> 
> Eventually, I'll get there...

Good.  -- Christian


From coleen.phillimore at oracle.com  Wed Sep 22 07:20:15 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 22 Sep 2010 10:20:15 -0400
Subject: Review request 6981484: Update development launcher
In-Reply-To: <3b7d727a-e930-4721-b064-1b539e7c9193@default>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>	<1284985103.14822.2285.camel@macbook>	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>	<1285087758.14822.3018.camel@macbook>	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default	1285159093.14822.3636.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
Message-ID: <4C9A109F.6040909@oracle.com>


Hi Staffan,
Is this file *src/os/windows/launcher/java.c**
*the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
In fact, the sources in os/linux/launcher are almost exactly the same as 
os/solaris/launcher.
Can we have just one set?  Perhaps put it in directory 
src/share/tools/launcher and make the makefiles use these sources 
instead? Sorry to make more work but having the same 2000 lines of code 
somewhere else, guarantees one copy will always be wrong.

Thanks,
Coleen

On 09/22/10 08:38, Staffan Larsen wrote:
> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>
> Eventually, I'll get there...
>
> Thanks,
> /Staffan
>
> -----Original Message-----
> From: Christian Thalinger 
> Sent: den 22 september 2010 2:38
> To: Staffan Larsen
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: Review request 6981484: Update development launcher
>
> On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
>   
>> Thanks Christian - I obviously have some things to learn as a new
>> committer - didn't think about the copyrights :-)
>>     
>
> Sure.  I was going the same route :-)
>
>   
>> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
>>
>> Now with updated copyrights.
>>     
>
> As David already said.
>
> -- Christian
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100922/35f27161/attachment.html 

From doug.simon at oracle.com  Wed Sep 22 08:20:39 2010
From: doug.simon at oracle.com (Douglas Simon)
Date: Wed, 22 Sep 2010 17:20:39 +0200
Subject: De-opt support and dependency tracking in HotSpot
References: <E3B39344-7D8D-4D0E-A6DE-AC21E39B8547@oracle.com>
Message-ID: <B977D778-87A4-43B2-B3E4-F7FC852AF13F@oracle.com>

Hi,

We are currently implementing de-opt support in the Maxine VM. I've just spent some time browsing HotSpot source code to see how dependencies are tracked for the purpose of speculative opts and de-opt. A very brief summary of what I've deduced is below. Any corrections/feedback/pointers to (non-code-embedded) documentation on this part of HotSpot would be greatly appreciated!

-Doug

Dependency tracking in HotSpot
==============================

A dependency is from a compiled method (i.e. nmethod) to a class (i.e. a klass). A dependency may be actually to specific method in a class but for the purpose of triggering dependency checking, it is the class in a dependency that matters. A compiled method can have more than one dependency and so each compiled method encodes a set of dependencies. A dependency is essentially a <DepType, klass> pair. For example, <concrete_with_no_concrete_subtype, java.util.HashMap>. When a new class is loaded, it is the root of a "dependency change set" (i.e. a DepChange) which is the super class hierarchy (including interfaces) rooted by the new class. The set of (live) compiled methods in the code cache is traversed just before the new class is registered in the system dictionary to see if any of them has a dependency in the dependency change set. If so and the assumption represented by the dependency is invalidated, then de-opt is triggered for the nmethod.

A potentially significant cost in this mechanism is the traversal of all methods in the code cache for each new class loaded. I assume this is done under the code cache lock. It may be that the cost of this in HotSpot is actually not so high as the number of nmethods code cache is relatively small (HotSpot has an interpreter). And it may also be mitigated by the fact that the cost of class loading dwarfs the cost of code cache traversals.


From kelly.ohair at oracle.com  Wed Sep 22 09:13:24 2010
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 22 Sep 2010 09:13:24 -0700
Subject: Review request 6981484: Update development launcher
In-Reply-To: <1285159693.14822.3647.camel@macbook>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default
	1285159093.14822.3636.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
	<1285159693.14822.3647.camel@macbook>
Message-ID: <5EDD2AE0-FD56-4002-84F1-F8B38ED1F924@oracle.com>


On Sep 22, 2010, at 5:48 AM, Christian Thalinger wrote:

> On Wed, 2010-09-22 at 05:38 -0700, Staffan Larsen wrote:
>> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>>
>> Eventually, I'll get there...
>
> Good.  -- Christian
>

Just sticking my nose in a little.  I think this syntax is not a great  
idea:
   84 $(LAUNCHER_SCRIPT): $(LAUNCHERDIR)/launcher.script
   85         $(QUIETLY) { \
   86         sed -e 's/@@LIBARCH@@/$(LIBARCH)/g' $< > $@; \
   87         chmod +x $@; \
   88         }

I think that if the sed command fails, the rule could still be  
successful if $@ exists.
Using subshells I usually encourage things like "(command1 &&  
command2)" so that command2
will not be run if command1 fails, and the subshell exits with a non- 
zero exit.
But I don't think you can use && with this shell {} syntax.

I would think this logic could be more predictable with something like:
   84 $(LAUNCHER_SCRIPT): $(LAUNCHERDIR)/launcher.script
   85         $(QUIETLY) $(RM) $@
   86         $(QUIETLY) sed -e 's/@@LIBARCH@@/$(LIBARCH)/g' $< > $@
   87         $(QUIETLY)chmod +x $@

Maybe even:
   84 $(LAUNCHER_SCRIPT): $(LAUNCHERDIR)/launcher.script
   85         $(QUIETLY) $(RM) $@
   86         $(QUIETLY) $(MKDIR) -p $(@D)
   87         $(QUIETLY) sed -e 's/@@LIBARCH@@/$(LIBARCH)/g' $< > $@
   88         $(QUIETLY) chmod +x $@



From staffan.larsen at oracle.com  Wed Sep 22 11:59:13 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Sep 2010 20:59:13 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <4C9A109F.6040909@oracle.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>	<1284985103.14822.2285.camel@macbook>	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>	<1285087758.14822.3018.camel@macbook>	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default	1285159093.14822.3636.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
	<4C9A109F.6040909@oracle.com>
Message-ID: <A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>

Thanks for the review, Coleen.

Yes, the files are almost identical and we should really have just one set. There were two main reasons why I duplicated the code, and neither of them is very good:

1) The code in /os/(linux|solaris)/launcher/* is based on the launcher in 1.6.0-b28 (at least the comment in java.c says so). I couldn't easily find that source code to grab the windows files from, so I got them from some other build (6.0u22-b01). There was enough difference between these to make the platform independent and platform dependent files incompatible. 
2) I didn't want to make more changes than I had to, so I didn't want to touch the linux or solaris launchers.

Perhaps there is even a third reason: There was already a precedent of having the linux and solaris code duplicated, so I just did the same thing for windows. Seems we would really benefit from a "posix" branch with common linux and solaris code in - in fact, the platform dependent parts of the launcher are the same for linux and solaris.

In retrospect, none of these reasons are good enough, and we should use the same code as much as possible. Any thoughts on what version on the launcher I should use as baseline? The latest one from jdk7? A stable one from jdk6?

Thanks,
/Staffan


On 22 sep 2010, at 16.20, Coleen Phillimore wrote:

> 
> Hi Staffan,
> Is this file src/os/windows/launcher/java.c
> the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
> In fact, the sources in os/linux/launcher are almost exactly the same as os/solaris/launcher.
> Can we have just one set?  Perhaps put it in directory src/share/tools/launcher and make the makefiles use these sources instead? Sorry to make more work but having the same 2000 lines of code somewhere else, guarantees one copy will always be wrong.
> 
> Thanks,
> Coleen
> 
> On 09/22/10 08:38, Staffan Larsen wrote:
>> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>> 
>> 
>> Eventually, I'll get there...
>> 
>> Thanks,
>> /Staffan
>> 
>> -----Original Message-----
>> From: Christian Thalinger 
>> Sent: den 22 september 2010 2:38
>> To: Staffan Larsen
>> Cc: 
>> hotspot-dev at openjdk.java.net
>> 
>> Subject: RE: Review request 6981484: Update development launcher
>> 
>> On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
>>   
>> 
>>> Thanks Christian - I obviously have some things to learn as a new
>>> committer - didn't think about the copyrights :-)
>>>     
>>> 
>> 
>> Sure.  I was going the same route :-)
>> 
>>   
>> 
>>> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
>>> 
>>> 
>>> Now with updated copyrights.
>>>     
>>> 
>> 
>> As David already said.
>> 
>> -- Christian
>> 
>>   
>> 
> 


From doug.simon at oracle.com  Wed Sep 22 12:22:22 2010
From: doug.simon at oracle.com (Douglas Simon)
Date: Wed, 22 Sep 2010 21:22:22 +0200
Subject: De-opt support and dependency tracking in HotSpot
In-Reply-To: <B977D778-87A4-43B2-B3E4-F7FC852AF13F@oracle.com>
References: <E3B39344-7D8D-4D0E-A6DE-AC21E39B8547@oracle.com>
	<B977D778-87A4-43B2-B3E4-F7FC852AF13F@oracle.com>
Message-ID: <E761F272-1993-43C7-9D5B-DBCD139DFFD9@oracle.com>

I've already received one correction. I was not aware of the _dependencies field in instanceKlass that lists the nmethods that have a dependency on that class. That is, there's no traversal of the code cache (for this purpose).

-Doug

On Sep 22, 2010, at 5:20 PM, Douglas Simon wrote:

> Hi,
> 
> We are currently implementing de-opt support in the Maxine VM. I've just spent some time browsing HotSpot source code to see how dependencies are tracked for the purpose of speculative opts and de-opt. A very brief summary of what I've deduced is below. Any corrections/feedback/pointers to (non-code-embedded) documentation on this part of HotSpot would be greatly appreciated!
> 
> -Doug
> 
> Dependency tracking in HotSpot
> ==============================
> 
> A dependency is from a compiled method (i.e. nmethod) to a class (i.e. a klass). A dependency may be actually to specific method in a class but for the purpose of triggering dependency checking, it is the class in a dependency that matters. A compiled method can have more than one dependency and so each compiled method encodes a set of dependencies. A dependency is essentially a <DepType, klass> pair. For example, <concrete_with_no_concrete_subtype, java.util.HashMap>. When a new class is loaded, it is the root of a "dependency change set" (i.e. a DepChange) which is the super class hierarchy (including interfaces) rooted by the new class. The set of (live) compiled methods in the code cache is traversed just before the new class is registered in the system dictionary to see if any of them has a dependency in the dependency change set. If so and the assumption represented by the dependency is invalidated, then de-opt is triggered for the nmethod.
> 
> A potentially significant cost in this mechanism is the traversal of all methods in the code cache for each new class loaded. I assume this is done under the code cache lock. It may be that the cost of this in HotSpot is actually not so high as the number of nmethods code cache is relatively small (HotSpot has an interpreter). And it may also be mitigated by the fact that the cost of class loading dwarfs the cost of code cache traversals.
> 


From tom.rodriguez at Oracle.com  Wed Sep 22 12:43:16 2010
From: tom.rodriguez at Oracle.com (Tom Rodriguez)
Date: Wed, 22 Sep 2010 12:43:16 -0700
Subject: De-opt support and dependency tracking in HotSpot
In-Reply-To: <E761F272-1993-43C7-9D5B-DBCD139DFFD9@oracle.com>
References: <E3B39344-7D8D-4D0E-A6DE-AC21E39B8547@oracle.com>
	<B977D778-87A4-43B2-B3E4-F7FC852AF13F@oracle.com>
	<E761F272-1993-43C7-9D5B-DBCD139DFFD9@oracle.com>
Message-ID: <A87803BC-890E-4852-B6A8-13BA52305F5C@oracle.com>


On Sep 22, 2010, at 12:22 PM, Douglas Simon wrote:

> I've already received one correction. I was not aware of the _dependencies field in instanceKlass that lists the nmethods that have a dependency on that class. That is, there's no traversal of the code cache (for this purpose).

That was an optimization we added a while back to reduce the overhead because the code cache can get quite large.  If I were going to rewrite the bookkeeping part I'd probably build a central database of dependencies instead of storing the information in the nmethod itself.  Scanning on the nmethods recorded by the class reduces the overhead but you still often end up checking the same dependency for each nmethod.  I think it would simplify the implementation quite a bit since we could skip the serialization machinery and the dependency logic could be easily captured by a base class with subclasses for the variants.  Each unique dependency would only be checked once as well.

The variety of dependencies is greater than just DepType, Klass though most of them fit within that schema.

int Dependencies::_dep_args[TYPE_LIMIT] = {
  -1,// end_marker
  1, // evol_method m
  1, // leaf_type ctxk
  2, // abstract_with_unique_concrete_subtype ctxk, k
  1, // abstract_with_no_concrete_subtype ctxk
  1, // concrete_with_no_concrete_subtype ctxk
  2, // unique_concrete_method ctxk, m
  3, // unique_concrete_subtypes_2 ctxk, k1, k2
  3, // unique_concrete_methods_2 ctxk, m1, m2
  1  // no_finalizable_subclasses ctxk
};

I don't think the _2 variants are currently in use.  The evol_method one is used to tracking inlining so that we can regenerate nmethods with classes are redefined, though this could be make more coarse grained by just recording the declaring klass.

tom

> 
> -Doug
> 
> On Sep 22, 2010, at 5:20 PM, Douglas Simon wrote:
> 
>> Hi,
>> 
>> We are currently implementing de-opt support in the Maxine VM. I've just spent some time browsing HotSpot source code to see how dependencies are tracked for the purpose of speculative opts and de-opt. A very brief summary of what I've deduced is below. Any corrections/feedback/pointers to (non-code-embedded) documentation on this part of HotSpot would be greatly appreciated!
>> 
>> -Doug
>> 
>> Dependency tracking in HotSpot
>> ==============================
>> 
>> A dependency is from a compiled method (i.e. nmethod) to a class (i.e. a klass). A dependency may be actually to specific method in a class but for the purpose of triggering dependency checking, it is the class in a dependency that matters. A compiled method can have more than one dependency and so each compiled method encodes a set of dependencies. A dependency is essentially a <DepType, klass> pair. For example, <concrete_with_no_concrete_subtype, java.util.HashMap>. When a new class is loaded, it is the root of a "dependency change set" (i.e. a DepChange) which is the super class hierarchy (including interfaces) rooted by the new class. The set of (live) compiled methods in the code cache is traversed just before the new class is registered in the system dictionary to see if any of them has a dependency in the dependency change set. If so and the assumption represented by the dependency is invalidated, then de-opt is triggered for the nmethod.
>> 
>> A potentially significant cost in this mechanism is the traversal of all methods in the code cache for each new class loaded. I assume this is done under the code cache lock. It may be that the cost of this in HotSpot is actually not so high as the number of nmethods code cache is relatively small (HotSpot has an interpreter). And it may also be mitigated by the fact that the cost of class loading dwarfs the cost of code cache traversals.
>> 
> 


From coleen.phillimore at oracle.com  Wed Sep 22 12:46:57 2010
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 22 Sep 2010 15:46:57 -0400
Subject: Review request 6981484: Update development launcher
In-Reply-To: <A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>	<1284985103.14822.2285.camel@macbook>	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>	<1285087758.14822.3018.camel@macbook>	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default	1285159093.14822.3636.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
	<4C9A109F.6040909@oracle.com>
	<A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>
Message-ID: <4C9A5D31.7070009@oracle.com>


Hi,

I think we should use the jdk7 version that you have in the windows 
build for all platforms. Many/most of the launcher jdk7 changes seem to 
be introducing the JLI layer and fixing some bugs. The platform 
dependent java_md.{ch} can be in os/<os>/launcher, and the java.c (which 
is the most code) in share/vm/tools/launcher - there isn't really risk 
to changing the solaris and linux versions since most people don't use 
them except for debugging. The only change that people would notice is 
if the libjvm.so is no longer statically linked in, because this is the 
primary benefit:

dbx gamma
stop in <some vm function> # no complaints from the debugger because 
libjvm.so is loaded already
run
<stop at break> # except this doesn't seem to work on linux now anyway

I can forsee using the launcher for development testing so having the 
latest jdk7 version makes a lot of sense, and having them consistent by 
platforms would be good going forward. I hope this isn't a ton of work 
to do though.

thanks,
Coleen

On 09/22/10 14:59, Staffan Larsen wrote:
> Thanks for the review, Coleen.
>
> Yes, the files are almost identical and we should really have just one set. There were two main reasons why I duplicated the code, and neither of them is very good:
>
> 1) The code in /os/(linux|solaris)/launcher/* is based on the launcher in 1.6.0-b28 (at least the comment in java.c says so). I couldn't easily find that source code to grab the windows files from, so I got them from some other build (6.0u22-b01). There was enough difference between these to make the platform independent and platform dependent files incompatible. 
> 2) I didn't want to make more changes than I had to, so I didn't want to touch the linux or solaris launchers.
>
> Perhaps there is even a third reason: There was already a precedent of having the linux and solaris code duplicated, so I just did the same thing for windows. Seems we would really benefit from a "posix" branch with common linux and solaris code in - in fact, the platform dependent parts of the launcher are the same for linux and solaris.
>
> In retrospect, none of these reasons are good enough, and we should use the same code as much as possible. Any thoughts on what version on the launcher I should use as baseline? The latest one from jdk7? A stable one from jdk6?
>
> Thanks,
> /Staffan
>
>
> On 22 sep 2010, at 16.20, Coleen Phillimore wrote:
>
>   
>> Hi Staffan,
>> Is this file src/os/windows/launcher/java.c
>> the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
>> In fact, the sources in os/linux/launcher are almost exactly the same as os/solaris/launcher.
>> Can we have just one set?  Perhaps put it in directory src/share/tools/launcher and make the makefiles use these sources instead? Sorry to make more work but having the same 2000 lines of code somewhere else, guarantees one copy will always be wrong.
>>
>> Thanks,
>> Coleen
>>
>> On 09/22/10 08:38, Staffan Larsen wrote:
>>     
>>> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>>>
>>>
>>> Eventually, I'll get there...
>>>
>>> Thanks,
>>> /Staffan
>>>
>>> -----Original Message-----
>>> From: Christian Thalinger 
>>> Sent: den 22 september 2010 2:38
>>> To: Staffan Larsen
>>> Cc: 
>>> hotspot-dev at openjdk.java.net
>>>
>>> Subject: RE: Review request 6981484: Update development launcher
>>>
>>> On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
>>>   
>>>
>>>       
>>>> Thanks Christian - I obviously have some things to learn as a new
>>>> committer - didn't think about the copyrights :-)
>>>>     
>>>>
>>>>         
>>> Sure.  I was going the same route :-)
>>>
>>>   
>>>
>>>       
>>>> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
>>>>
>>>>
>>>> Now with updated copyrights.
>>>>     
>>>>
>>>>         
>>> As David already said.
>>>
>>> -- Christian
>>>
>>>   
>>>
>>>       
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100922/b1d344fc/attachment.html 

From magnus.ihse.bursie at oracle.com  Thu Sep 23 00:04:32 2010
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 23 Sep 2010 09:04:32 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <4C9A5D31.7070009@oracle.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>	<1284985103.14822.2285.camel@macbook>	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>	<1285087758.14822.3018.camel@macbook>	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default	1285159093.14822.3636.camel@macbook>	<3b7d727a-e930-4721-b064-1b539e7c9193@default>	<4C9A109F.6040909@oracle.com>	<A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>
	<4C9A5D31.7070009@oracle.com>
Message-ID: <4C9AFC00.6020200@oracle.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100923/647b1de1/attachment-0001.html 

From christian.thalinger at oracle.com  Thu Sep 23 02:12:24 2010
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 23 Sep 2010 11:12:24 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <4C9AFC00.6020200@oracle.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default	1285159093.14822.3636.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
	<4C9A109F.6040909@oracle.com>
	<A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>
	<4C9A5D31.7070009@oracle.com>  <4C9AFC00.6020200@oracle.com>
Message-ID: <1285233144.14822.4151.camel@macbook>

On Thu, 2010-09-23 at 09:04 +0200, Magnus Ihse Bursie wrote:
> On 2010-09-22 21.46, Coleen Phillimore wrote: 
> > 
> > The only change that people would notice is if the libjvm.so is no
> > longer statically linked in, because this is the primary benefit:
> > 
> > dbx gamma
> > stop in <some vm function>  # no complaints from the debugger
> > because libjvm.so is loaded already
> > run
> > <stop at break>    # except this doesn't seem to work on linux now
> > anyway
> 
> Having libjvm.so statically linked in the loader seems to me like a
> way to just cause the resulting build to be twice as large as needed.

That's not true.  libjvm.so is not statically linked into gamma:

$ ls -l gamma libjvm.so
-rwxr-xr-x 1 twisti twisti     69725 2010-09-22 10:39 gamma*
-rwxr-xr-x 1 twisti twisti 134354760 2010-09-22 10:39 libjvm.so*
$ ldd gamma
	linux-vdso.so.1 =>  (0x00007fff1dfa8000)
	libjvm.so => not found
	libm.so.6 => /lib/libm.so.6 (0x00007f622580f000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f622560b000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f62253ee000)
	libc.so.6 => /lib/libc.so.6 (0x00007f622506a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6225ab0000)

But DBX loads the libraries which it is linked against on startup and
you can set breakpoints right away:

$ dbx ./gamma
# Loading linux_amd64_compiler2/jvmg/.dbxrc
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc
Reading gamma
Reading ld-linux-x86-64.so.2
Reading libjvm.so
Reading libm.so.6
Reading libdl.so.2
Reading libpthread.so.0
Reading libc.so.6
(dbx) stop in Output
dbx: warning: 'Output' has no debugger info -- will trigger on first instruction
(2) stop in `libjvm.so`idealGraphPrinter.cpp`#_ZN7Compile6OutputEv	[non -g, demangles to: Compile::Output()]
(dbx) 

-- Christian


From sylvestre.ledru at scilab.org  Thu Sep 23 02:25:19 2010
From: sylvestre.ledru at scilab.org (Sylvestre Ledru)
Date: Thu, 23 Sep 2010 11:25:19 +0200
Subject: Unknown error reported in the JNI "JNI_CreateJavaVM"
In-Reply-To: <4C907932.2090402@oracle.com>
References: <1284535070.17296.214.camel@korcula.inria.fr>
	<4C907932.2090402@oracle.com>
Message-ID: <1285233919.13920.4604.camel@korcula.inria.fr>

Hello David,

Le mercredi 15 septembre 2010 ? 17:43 +1000, David Holmes a ?crit :
> Sylvestre Ledru said the following on 09/15/10 17:17:
> > As suggested in the bug report:
> > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=553
> > I am contacting you about an small issue.
> > 
> > Starting the JVM a few times with "JNI_CreateJavaVM" may lead to an
> > error JNI_ERR ("unknown error").
> > However, it could return JNI_EEXIST ("VM already created") which will be
> > more interesting to manage the error and debugging. This error code is
> > already defined in jni.h.
> 
> This is a curious part of the JNI spec as it doesn't actually define a 
> set of error codes, even though jni.h does contain a few, including 
> JNI_EEXIST. But at least we aren't constrained by the spec as 
> CreateJavaVM is allowed to return a "a suitable JNI error code (a 
> negative number) on failure".
> 
> The question is, is it too late to change this? Any code that checks for 
> JNI_ERR will now be broken, but code that checks for !JNI_OK will be fine.
I can't answer to this question but having this patch applied would save
some time and simplify the debugging.
JNI_ERR is too generic and doesn't provide enough information when this
error occurs... 

Thanks for your quick reply,
Sylvestre


From keith.mcguigan at oracle.com  Thu Sep 23 06:20:49 2010
From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com)
Date: Thu, 23 Sep 2010 13:20:49 +0000
Subject: hg: jdk7/hotspot/hotspot: 9 new changesets
Message-ID: <20100923132107.4638547BA7@hg.openjdk.java.net>

Changeset: 883a82d6d41d
Author:    acorn
Date:      2010-09-10 12:36 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/883a82d6d41d

6942092: Loader-constraint test is failing
Summary: Fix test string compare to match source update
Reviewed-by: dcubed, phh

! test/runtime/6626217/Test6626217.sh

Changeset: 6cde0ed1b568
Author:    acorn
Date:      2010-09-14 10:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6cde0ed1b568

Merge


Changeset: 4094f07967ca
Author:    kamg
Date:      2010-09-15 16:28 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4094f07967ca

6974813: JVM needs to use demand loading for its DTrace probes
Summary: Pass -xlazyload to the 'dtrace -G' invocation
Reviewed-by: phh, ysr

! make/solaris/makefiles/dtrace.make

Changeset: 728a287f6c20
Author:    zgu
Date:      2010-09-17 09:45 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/728a287f6c20

6981753: Rebrand vm vendor property settings
Summary: Uses JDK_Version to determinate to set vm vendor to "Oracle Corporation" for JDK7 and later.
Reviewed-by: kamg, ohair, coleenp

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

Changeset: 51640ecd89f8
Author:    zgu
Date:      2010-09-17 09:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/51640ecd89f8

Merge


Changeset: 3babdb042f25
Author:    kamg
Date:      2010-09-17 19:45 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3babdb042f25

Merge


Changeset: 60f88489896f
Author:    kamg
Date:      2010-09-20 15:38 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/60f88489896f

6975210: java.lang.VerifyError in some of JCK tests
Summary: Naked oop in verificationType::is_reference_assignable_from()
Reviewed-by: never, kvn, coleenp

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

Changeset: 2966dab85b3e
Author:    dcubed
Date:      2010-09-21 06:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2966dab85b3e

6985848: 3/4 fix for 6561870 causes sa-jdi.jar to be rebuilt every time
Summary: Refine fix for 6561870 to only rebuild sa-jdi.jar when needed
Reviewed-by: never, ohair, coleenp

! make/linux/makefiles/sa.make
! make/solaris/makefiles/sa.make

Changeset: a25394352030
Author:    kamg
Date:      2010-09-22 12:54 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a25394352030

Merge

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


From volker.simonis at gmail.com  Thu Sep 23 08:13:05 2010
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 23 Sep 2010 17:13:05 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <4C9A5D31.7070009@oracle.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
	<4C9A109F.6040909@oracle.com>
	<A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>
	<4C9A5D31.7070009@oracle.com>
Message-ID: <AANLkTi=Afjm9w_0NEq-E6ggHRJLqUkdqO9gtoWjg_1zO@mail.gmail.com>

Hi,

I think the main problem is not that we have two (in fact four)
launchers, but that they are located in two workspaces.

The main reason why I use 'gamma' is because I usually only build the
'hotspot' project and not 'jdk' which contains the standard 'java'
launcher.

Another reason for using 'gamma' is that it doesn't do a 'execv()'
system call to run with a new LD_LIBRARY_PATH like this is done by
'java' launcher. This  'execv()' usually confuses debuggers. In order
to avoid it, one has to set the right LD_LIBRARY_PATH (i.e. the one
that would be build by the launcher anyway) before calling 'java'.
This all is kind of "how to debug the HotSpot" wizard knowledge spread
over various blogs and email threads.

I don't really see a problem in the fact that libjvm.so doesn't get
loaded when the launcher is started. Just do a first run with:

(gdb) run -version

which loads all the necessary dynamic objects. Then it's easily
possible to set breakpoints wherever you want. (And double checking
that you debug the right version of libjvm.so is never a fault:)

To cut a long story short:
- I don't think that its possible to keep two launchers in sync if
they are in different workspaces ('hotspot' and 'jdk') nor do I think
that it's possible to factor out some common code between the two
workspaces.
- We should have a launcher in Hotspot which is as simple as possible
and not dependant on the one from 'jdk' anymore. Therefore it doesn't
really matter where we start from (taking the one from jdk7 would be a
natural choice though)
- as much as possible common code of the new HotSpot launcher ('gamma'
or 'fusion' or whatever..)should be factored out into the shared code
space (/share/vm/tools/..).
- the main design goal of the new launcher should be easy
'debuggability' (i.e. no execv()) and an easy possibility to chose a
runtime JDK to run with (from command line or from the environment).

Regards,
Volker

On Wed, Sep 22, 2010 at 9:46 PM, Coleen Phillimore
<coleen.phillimore at oracle.com> wrote:
>
> Hi,
>
> I think we should use the jdk7 version that you have in the windows build
> for all platforms.? Many/most of the launcher jdk7 changes seem to be
> introducing the JLI layer and fixing some bugs. ?? The platform dependent
> java_md.{ch} can be in os/<os>/launcher, and the java.c (which is the most
> code) in share/vm/tools/launcher - there isn't really risk to changing the
> solaris and linux versions since most people don't use them except for
> debugging.? The only change that people would notice is if the libjvm.so is
> no longer statically linked in, because this is the primary benefit:
>
> dbx gamma
> stop in <some vm function>? # no complaints from the debugger because
> libjvm.so is loaded already
> run
> <stop at break>??? # except this doesn't seem to work on linux now anyway
>
> I can forsee using the launcher for development testing so having the latest
> jdk7 version makes a lot of sense, and having them consistent by platforms
> would be good going forward.?? I hope this isn't a ton of work to do though.
>
> thanks,
> Coleen
>
> On 09/22/10 14:59, Staffan Larsen wrote:
>
> Thanks for the review, Coleen.
>
> Yes, the files are almost identical and we should really have just one set.
> There were two main reasons why I duplicated the code, and neither of them
> is very good:
>
> 1) The code in /os/(linux|solaris)/launcher/* is based on the launcher in
> 1.6.0-b28 (at least the comment in java.c says so). I couldn't easily find
> that source code to grab the windows files from, so I got them from some
> other build (6.0u22-b01). There was enough difference between these to make
> the platform independent and platform dependent files incompatible.
> 2) I didn't want to make more changes than I had to, so I didn't want to
> touch the linux or solaris launchers.
>
> Perhaps there is even a third reason: There was already a precedent of
> having the linux and solaris code duplicated, so I just did the same thing
> for windows. Seems we would really benefit from a "posix" branch with common
> linux and solaris code in - in fact, the platform dependent parts of the
> launcher are the same for linux and solaris.
>
> In retrospect, none of these reasons are good enough, and we should use the
> same code as much as possible. Any thoughts on what version on the launcher
> I should use as baseline? The latest one from jdk7? A stable one from jdk6?
>
> Thanks,
> /Staffan
>
>
> On 22 sep 2010, at 16.20, Coleen Phillimore wrote:
>
>
>
> Hi Staffan,
> Is this file src/os/windows/launcher/java.c
> the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
> In fact, the sources in os/linux/launcher are almost exactly the same as
> os/solaris/launcher.
> Can we have just one set?  Perhaps put it in directory
> src/share/tools/launcher and make the makefiles use these sources instead?
> Sorry to make more work but having the same 2000 lines of code somewhere
> else, guarantees one copy will always be wrong.
>
> Thanks,
> Coleen
>
> On 09/22/10 08:38, Staffan Larsen wrote:
>
>
> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>
>
> Eventually, I'll get there...
>
> Thanks,
> /Staffan
>
> -----Original Message-----
> From: Christian Thalinger
> Sent: den 22 september 2010 2:38
> To: Staffan Larsen
> Cc:
> hotspot-dev at openjdk.java.net
>
> Subject: RE: Review request 6981484: Update development launcher
>
> On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
>
>
>
>
> Thanks Christian - I obviously have some things to learn as a new
> committer - didn't think about the copyrights :-)
>
>
>
>
> Sure.  I was going the same route :-)
>
>
>
>
>
> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
>
>
> Now with updated copyrights.
>
>
>
>
> As David already said.
>
> -- Christian
>
>
>
>
>
>
>

From rasbold at google.com  Thu Sep 23 16:35:15 2010
From: rasbold at google.com (Chuck Rasbold)
Date: Thu, 23 Sep 2010 16:35:15 -0700
Subject: Review request 6985422: flush the output streams before OnError
	commands
In-Reply-To: <4C97F52B.7070608@oracle.com>
References: <4C924FFE.607@oracle.com> <4C92AED1.3010906@oracle.com>
	<AANLkTik_boQfAtzRX2aLA_NKs4yv4fevT1NUgRP0kQd9@mail.gmail.com>
	<4C9703D2.9080701@oracle.com>
	<AANLkTikN+01VAj5aBKowddrimq=7mzWbr2e3sqxYSoru@mail.gmail.com>
	<4C97F52B.7070608@oracle.com>
Message-ID: <AANLkTimjfbeds_kq3w+X9L5e0xhHLkbditdagiBvHpkV@mail.gmail.com>

On Mon, Sep 20, 2010 at 4:58 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Chuck Rasbold said the following on 09/21/10 04:15:
>
>  The "aborting" that ostream_abort() does is to flush and merge the
>> LogCompilation files.  That behavior is what we desire before OnError
>> commands are processed.
>>
>
> flush I can understand.
>
>
>  I could factor out an ostream_flush() function, but ithere's no place we'd
>> want to call it.
>>
>> So is this OK?
>>
>> http://cr.openjdk.java.net/~rasbold/6985422/webrev.00
>>
>
> Yes, in that calling ostream_abort() a second time in os::shutdown will be
> a no-op.
>
> My only lingering concern is that while one thread is reporting this fatal
> error the rest of the VM continues to execute, and those other threads might
> encounter a stream/log-file that has now been closed. I don't know if this
> would be handled gracefully or whether we care one way or the other. We have
> the same issue with the ostream_abort in os::shutdown but the window between
> closing the files and blowing away the process is very small. In this case
> your onError commands could take an indeterminate amount of time during
> which the rest of the VM continues to execute.
>

Certainly, the OnError commands may take indeterminate amount of time. And I
admit that any OnError command, because it is run by "sh", will dominate any
tiny window between ostream_abort and the end of os:;shutdown().

However, the nature of OnError is that it gives the user one last chance to
attempt some processing.

In my user's case, he loses access to the files when the JVM dies. The
LogCompilation information of a crash is lost if it isn't captured at
OnError time.  Compiles done after report_and_die() is called are of little
interest compared to the compiler state when the error happens.

-- Chuck


> David
>
>  -- Chuck
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100923/6225b5da/attachment.html 

From erik.trimble at oracle.com  Fri Sep 24 01:45:51 2010
From: erik.trimble at oracle.com (erik.trimble at oracle.com)
Date: Fri, 24 Sep 2010 08:45:51 +0000
Subject: hg: jdk7/hotspot/hotspot: 7 new changesets
Message-ID: <20100924084606.233C647BDD@hg.openjdk.java.net>

Changeset: 2fe09e2e70d0
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2fe09e2e70d0

Added tag jdk7-b108 for changeset e44a93947ccb

! .hgtags

Changeset: cc4bb3022b31
Author:    cl
Date:      2010-09-09 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cc4bb3022b31

Merge

! .hgtags
- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 2f25f2b8de27
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2f25f2b8de27

Added tag jdk7-b109 for changeset cc4bb3022b31

! .hgtags

Changeset: 07b042e13dde
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07b042e13dde

Added tag jdk7-b110 for changeset 2f25f2b8de27

! .hgtags

Changeset: 8d5897b4230f
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8d5897b4230f

Added tag jdk7-b111 for changeset 07b042e13dde

! .hgtags

Changeset: 9bdbd693dbaa
Author:    trims
Date:      2010-09-24 00:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9bdbd693dbaa

Merge


Changeset: b2045e0af26e
Author:    trims
Date:      2010-09-24 00:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b2045e0af26e

6987149: Fix incorrect Oracle copyright header in make/templates files
Summary: Minor fix to first line of template copyright files
Reviewed-by: ohair

! make/templates/bsd-header
! make/templates/gpl-cp-header
! make/templates/gpl-header


From volker.simonis at gmail.com  Fri Sep 24 09:47:23 2010
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Sep 2010 18:47:23 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <AANLkTi=Afjm9w_0NEq-E6ggHRJLqUkdqO9gtoWjg_1zO@mail.gmail.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
	<4C9A109F.6040909@oracle.com>
	<A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>
	<4C9A5D31.7070009@oracle.com>
	<AANLkTi=Afjm9w_0NEq-E6ggHRJLqUkdqO9gtoWjg_1zO@mail.gmail.com>
Message-ID: <AANLkTinQzbNHhLUczLC4ov7yqE9GzDgUPzH1Xm5Rz4Q6@mail.gmail.com>

.. and I forgot to attach the following maybe usefull links to Joe
Darcy's blogs about the problems and recent reengineering of the
default Java launcher:

What is the launcher? at http://blogs.sun.com/darcy/entry/what_is_the_launcher
Purging LD_LIBRARY_PATH at
http://blogs.sun.com/darcy/entry/purging_ld_library_path

Regards,
Volker

On Thu, Sep 23, 2010 at 5:13 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> I think the main problem is not that we have two (in fact four)
> launchers, but that they are located in two workspaces.
>
> The main reason why I use 'gamma' is because I usually only build the
> 'hotspot' project and not 'jdk' which contains the standard 'java'
> launcher.
>
> Another reason for using 'gamma' is that it doesn't do a 'execv()'
> system call to run with a new LD_LIBRARY_PATH like this is done by
> 'java' launcher. This ?'execv()' usually confuses debuggers. In order
> to avoid it, one has to set the right LD_LIBRARY_PATH (i.e. the one
> that would be build by the launcher anyway) before calling 'java'.
> This all is kind of "how to debug the HotSpot" wizard knowledge spread
> over various blogs and email threads.
>
> I don't really see a problem in the fact that libjvm.so doesn't get
> loaded when the launcher is started. Just do a first run with:
>
> (gdb) run -version
>
> which loads all the necessary dynamic objects. Then it's easily
> possible to set breakpoints wherever you want. (And double checking
> that you debug the right version of libjvm.so is never a fault:)
>
> To cut a long story short:
> - I don't think that its possible to keep two launchers in sync if
> they are in different workspaces ('hotspot' and 'jdk') nor do I think
> that it's possible to factor out some common code between the two
> workspaces.
> - We should have a launcher in Hotspot which is as simple as possible
> and not dependant on the one from 'jdk' anymore. Therefore it doesn't
> really matter where we start from (taking the one from jdk7 would be a
> natural choice though)
> - as much as possible common code of the new HotSpot launcher ('gamma'
> or 'fusion' or whatever..)should be factored out into the shared code
> space (/share/vm/tools/..).
> - the main design goal of the new launcher should be easy
> 'debuggability' (i.e. no execv()) and an easy possibility to chose a
> runtime JDK to run with (from command line or from the environment).
>
> Regards,
> Volker
>
> On Wed, Sep 22, 2010 at 9:46 PM, Coleen Phillimore
> <coleen.phillimore at oracle.com> wrote:
>>
>> Hi,
>>
>> I think we should use the jdk7 version that you have in the windows build
>> for all platforms.? Many/most of the launcher jdk7 changes seem to be
>> introducing the JLI layer and fixing some bugs. ?? The platform dependent
>> java_md.{ch} can be in os/<os>/launcher, and the java.c (which is the most
>> code) in share/vm/tools/launcher - there isn't really risk to changing the
>> solaris and linux versions since most people don't use them except for
>> debugging.? The only change that people would notice is if the libjvm.so is
>> no longer statically linked in, because this is the primary benefit:
>>
>> dbx gamma
>> stop in <some vm function>? # no complaints from the debugger because
>> libjvm.so is loaded already
>> run
>> <stop at break>??? # except this doesn't seem to work on linux now anyway
>>
>> I can forsee using the launcher for development testing so having the latest
>> jdk7 version makes a lot of sense, and having them consistent by platforms
>> would be good going forward.?? I hope this isn't a ton of work to do though.
>>
>> thanks,
>> Coleen
>>
>> On 09/22/10 14:59, Staffan Larsen wrote:
>>
>> Thanks for the review, Coleen.
>>
>> Yes, the files are almost identical and we should really have just one set.
>> There were two main reasons why I duplicated the code, and neither of them
>> is very good:
>>
>> 1) The code in /os/(linux|solaris)/launcher/* is based on the launcher in
>> 1.6.0-b28 (at least the comment in java.c says so). I couldn't easily find
>> that source code to grab the windows files from, so I got them from some
>> other build (6.0u22-b01). There was enough difference between these to make
>> the platform independent and platform dependent files incompatible.
>> 2) I didn't want to make more changes than I had to, so I didn't want to
>> touch the linux or solaris launchers.
>>
>> Perhaps there is even a third reason: There was already a precedent of
>> having the linux and solaris code duplicated, so I just did the same thing
>> for windows. Seems we would really benefit from a "posix" branch with common
>> linux and solaris code in - in fact, the platform dependent parts of the
>> launcher are the same for linux and solaris.
>>
>> In retrospect, none of these reasons are good enough, and we should use the
>> same code as much as possible. Any thoughts on what version on the launcher
>> I should use as baseline? The latest one from jdk7? A stable one from jdk6?
>>
>> Thanks,
>> /Staffan
>>
>>
>> On 22 sep 2010, at 16.20, Coleen Phillimore wrote:
>>
>>
>>
>> Hi Staffan,
>> Is this file src/os/windows/launcher/java.c
>> the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
>> In fact, the sources in os/linux/launcher are almost exactly the same as
>> os/solaris/launcher.
>> Can we have just one set? ?Perhaps put it in directory
>> src/share/tools/launcher and make the makefiles use these sources instead?
>> Sorry to make more work but having the same 2000 lines of code somewhere
>> else, guarantees one copy will always be wrong.
>>
>> Thanks,
>> Coleen
>>
>> On 09/22/10 08:38, Staffan Larsen wrote:
>>
>>
>> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>>
>>
>> Eventually, I'll get there...
>>
>> Thanks,
>> /Staffan
>>
>> -----Original Message-----
>> From: Christian Thalinger
>> Sent: den 22 september 2010 2:38
>> To: Staffan Larsen
>> Cc:
>> hotspot-dev at openjdk.java.net
>>
>> Subject: RE: Review request 6981484: Update development launcher
>>
>> On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
>>
>>
>>
>>
>> Thanks Christian - I obviously have some things to learn as a new
>> committer - didn't think about the copyrights :-)
>>
>>
>>
>>
>> Sure. ?I was going the same route :-)
>>
>>
>>
>>
>>
>> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
>>
>>
>> Now with updated copyrights.
>>
>>
>>
>>
>> As David already said.
>>
>> -- Christian
>>
>>
>>
>>
>>
>>
>>
>

From staffan.larsen at oracle.com  Fri Sep 24 12:27:55 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 24 Sep 2010 21:27:55 +0200
Subject: Review request 6981484: Update development launcher
In-Reply-To: <AANLkTinQzbNHhLUczLC4ov7yqE9GzDgUPzH1Xm5Rz4Q6@mail.gmail.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default>
	<4C9A109F.6040909@oracle.com>
	<A8E326D5-4BA7-47FD-A887-201AA71B4AED@oracle.com>
	<4C9A5D31.7070009@oracle.com>
	<AANLkTi=Afjm9w_0NEq-E6ggHRJLqUkdqO9gtoWjg_1zO@mail.gmail.com>
	<AANLkTinQzbNHhLUczLC4ov7yqE9GzDgUPzH1Xm5Rz4Q6@mail.gmail.com>
Message-ID: <1A07D090-EE64-4E69-A667-FD7B789963DC@oracle.com>

Thanks for the pointers. For the development launcher, things are much simpler since there is only one JVM it can and will launch (the one in the same directory as the launcher). This removes all need for execv(). 

To set up the correct LD_LIBRARY_PATH, I use a script in front of the well-known gamma launcher. This script sets up LD_LIBRARY_PATH, as well as launching the process in a debugger if requested. When launching in a debugger the script sets a breakpoint in a well-known method in the launcher after libraries have been loaded. Thus when you get to the prompt in the debugger libraries are loaded and you can set breakpoints as you'd like. This also makes it easy to set all command line options before launching the debugger. To launch in gdb would look something like:

> fusion -gdb -cp my/path/here -XX:+SomeFlagHere MyProgram

It also turns out that we can't use the jdk7 launcher since it has been rewritten and cannot launch jdk6 anymore. 

Regards,
/Staffan


On 24 sep 2010, at 18.47, Volker Simonis wrote:

> .. and I forgot to attach the following maybe usefull links to Joe
> Darcy's blogs about the problems and recent reengineering of the
> default Java launcher:
> 
> What is the launcher? at http://blogs.sun.com/darcy/entry/what_is_the_launcher
> Purging LD_LIBRARY_PATH at
> http://blogs.sun.com/darcy/entry/purging_ld_library_path
> 
> Regards,
> Volker
> 
> On Thu, Sep 23, 2010 at 5:13 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>> 
>> I think the main problem is not that we have two (in fact four)
>> launchers, but that they are located in two workspaces.
>> 
>> The main reason why I use 'gamma' is because I usually only build the
>> 'hotspot' project and not 'jdk' which contains the standard 'java'
>> launcher.
>> 
>> Another reason for using 'gamma' is that it doesn't do a 'execv()'
>> system call to run with a new LD_LIBRARY_PATH like this is done by
>> 'java' launcher. This  'execv()' usually confuses debuggers. In order
>> to avoid it, one has to set the right LD_LIBRARY_PATH (i.e. the one
>> that would be build by the launcher anyway) before calling 'java'.
>> This all is kind of "how to debug the HotSpot" wizard knowledge spread
>> over various blogs and email threads.
>> 
>> I don't really see a problem in the fact that libjvm.so doesn't get
>> loaded when the launcher is started. Just do a first run with:
>> 
>> (gdb) run -version
>> 
>> which loads all the necessary dynamic objects. Then it's easily
>> possible to set breakpoints wherever you want. (And double checking
>> that you debug the right version of libjvm.so is never a fault:)
>> 
>> To cut a long story short:
>> - I don't think that its possible to keep two launchers in sync if
>> they are in different workspaces ('hotspot' and 'jdk') nor do I think
>> that it's possible to factor out some common code between the two
>> workspaces.
>> - We should have a launcher in Hotspot which is as simple as possible
>> and not dependant on the one from 'jdk' anymore. Therefore it doesn't
>> really matter where we start from (taking the one from jdk7 would be a
>> natural choice though)
>> - as much as possible common code of the new HotSpot launcher ('gamma'
>> or 'fusion' or whatever..)should be factored out into the shared code
>> space (/share/vm/tools/..).
>> - the main design goal of the new launcher should be easy
>> 'debuggability' (i.e. no execv()) and an easy possibility to chose a
>> runtime JDK to run with (from command line or from the environment).
>> 
>> Regards,
>> Volker
>> 
>> On Wed, Sep 22, 2010 at 9:46 PM, Coleen Phillimore
>> <coleen.phillimore at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I think we should use the jdk7 version that you have in the windows build
>>> for all platforms.  Many/most of the launcher jdk7 changes seem to be
>>> introducing the JLI layer and fixing some bugs.    The platform dependent
>>> java_md.{ch} can be in os/<os>/launcher, and the java.c (which is the most
>>> code) in share/vm/tools/launcher - there isn't really risk to changing the
>>> solaris and linux versions since most people don't use them except for
>>> debugging.  The only change that people would notice is if the libjvm.so is
>>> no longer statically linked in, because this is the primary benefit:
>>> 
>>> dbx gamma
>>> stop in <some vm function>  # no complaints from the debugger because
>>> libjvm.so is loaded already
>>> run
>>> <stop at break>    # except this doesn't seem to work on linux now anyway
>>> 
>>> I can forsee using the launcher for development testing so having the latest
>>> jdk7 version makes a lot of sense, and having them consistent by platforms
>>> would be good going forward.   I hope this isn't a ton of work to do though.
>>> 
>>> thanks,
>>> Coleen
>>> 
>>> On 09/22/10 14:59, Staffan Larsen wrote:
>>> 
>>> Thanks for the review, Coleen.
>>> 
>>> Yes, the files are almost identical and we should really have just one set.
>>> There were two main reasons why I duplicated the code, and neither of them
>>> is very good:
>>> 
>>> 1) The code in /os/(linux|solaris)/launcher/* is based on the launcher in
>>> 1.6.0-b28 (at least the comment in java.c says so). I couldn't easily find
>>> that source code to grab the windows files from, so I got them from some
>>> other build (6.0u22-b01). There was enough difference between these to make
>>> the platform independent and platform dependent files incompatible.
>>> 2) I didn't want to make more changes than I had to, so I didn't want to
>>> touch the linux or solaris launchers.
>>> 
>>> Perhaps there is even a third reason: There was already a precedent of
>>> having the linux and solaris code duplicated, so I just did the same thing
>>> for windows. Seems we would really benefit from a "posix" branch with common
>>> linux and solaris code in - in fact, the platform dependent parts of the
>>> launcher are the same for linux and solaris.
>>> 
>>> In retrospect, none of these reasons are good enough, and we should use the
>>> same code as much as possible. Any thoughts on what version on the launcher
>>> I should use as baseline? The latest one from jdk7? A stable one from jdk6?
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> 
>>> On 22 sep 2010, at 16.20, Coleen Phillimore wrote:
>>> 
>>> 
>>> 
>>> Hi Staffan,
>>> Is this file src/os/windows/launcher/java.c
>>> the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
>>> In fact, the sources in os/linux/launcher are almost exactly the same as
>>> os/solaris/launcher.
>>> Can we have just one set?  Perhaps put it in directory
>>> src/share/tools/launcher and make the makefiles use these sources instead?
>>> Sorry to make more work but having the same 2000 lines of code somewhere
>>> else, guarantees one copy will always be wrong.
>>> 
>>> Thanks,
>>> Coleen
>>> 
>>> On 09/22/10 08:38, Staffan Larsen wrote:
>>> 
>>> 
>>> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>>> 
>>> 
>>> Eventually, I'll get there...
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger
>>> Sent: den 22 september 2010 2:38
>>> To: Staffan Larsen
>>> Cc:
>>> hotspot-dev at openjdk.java.net
>>> 
>>> Subject: RE: Review request 6981484: Update development launcher
>>> 
>>> On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
>>> 
>>> 
>>> 
>>> 
>>> Thanks Christian - I obviously have some things to learn as a new
>>> committer - didn't think about the copyrights :-)
>>> 
>>> 
>>> 
>>> 
>>> Sure.  I was going the same route :-)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
>>> 
>>> 
>>> Now with updated copyrights.
>>> 
>>> 
>>> 
>>> 
>>> As David already said.
>>> 
>>> -- Christian
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 


From erik.trimble at oracle.com  Tue Sep 28 13:58:07 2010
From: erik.trimble at oracle.com (erik.trimble at oracle.com)
Date: Tue, 28 Sep 2010 20:58:07 +0000
Subject: hg: hsx/hsx19/baseline: 6987149: Fix incorrect Oracle copyright
	header in make/templates files
Message-ID: <20100928205808.C936547CFB@hg.openjdk.java.net>

Changeset: d3b3540db4c3
Author:    trims
Date:      2010-09-24 00:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d3b3540db4c3

6987149: Fix incorrect Oracle copyright header in make/templates files
Summary: Minor fix to first line of template copyright files
Reviewed-by: ohair

! make/templates/bsd-header
! make/templates/gpl-cp-header
! make/templates/gpl-header


From staffan.larsen at oracle.com  Wed Sep 29 06:38:35 2010
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 29 Sep 2010 06:38:35 -0700 (PDT)
Subject: Review request 6981484: Update development launcher
In-Reply-To: <4C9A109F.6040909@oracle.com>
References: <41c46841-693e-4bed-ac89-29cff7867a50@default>
	<1284985103.14822.2285.camel@macbook>
	<50ee9673-7a05-48ce-954a-3541eca08e2a@default>
	<1285087758.14822.3018.camel@macbook>
	<629026fb-5d9f-4760-a2c4-fb945998f0c1@default
	1285159093.14822.3636.camel@macbook>
	<3b7d727a-e930-4721-b064-1b539e7c9193@default
	4C9A109F.6040909@oracle.com>
Message-ID: <c3289a9a-e020-431a-a5b3-ee75a72a05b3@default>

Hi All,

?

So, another shot: http://cr.openjdk.java.net/~sla/6981484/webrev.04/

?

This time I have based the launcher code on JDK 6u22. I am using the same code for all platforms. Shared code are in src/share/tools/launcher. To minimize code duplication I have placed the shared solaris/linux code in src/os/posix/launcher. The windows code is in src/os/windows/launcher.

?

The launcher is now called hotspot(.exe). It will choose the JDK to use based on the values of JAVA_HOME or ALT_JAVA_HOME (the latter takes precedence).

?

The windows launcher is a normal executable with dynamic linking of jvm.dll. It has no special arguments.

?

The posix launcher is really a shell script that sets up LD_LIBRARY_PATH and some other things before calling the executable. The executable is still called gamma and is dynamically linked to libjvm.so. The posix launcher accepts the following arguments:

??-gdb: launches gdb and runs the launcher until libjvm.so is loaded (to make it easier to set breakpoints)

??-gud: same as -gdb, but launches emacs in gud-mode.

??-dbx: launches dbx

? -valgrind: launches in the valgrind environment (if available)

?

Thanks,

/Staffan

?

?

From: Coleen Phillimore 
Sent: den 22 september 2010 4:20
To: Staffan Larsen
Cc: Christian Thalinger; hotspot-dev at openjdk.java.net
Subject: Re: Review request 6981484: Update development launcher

?


Hi Staffan,
Is this file src/os/windows/launcher/java.c
the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
In fact, the sources in os/linux/launcher are almost exactly the same as os/solaris/launcher.
Can we have just one set?? Perhaps put it in directory src/share/tools/launcher and make the makefiles use these sources instead? Sorry to make more work but having the same 2000 lines of code somewhere else, guarantees one copy will always be wrong.

Thanks,
Coleen

On 09/22/10 08:38, Staffan Larsen wrote: 

Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
?
Eventually, I'll get there...
?
Thanks,
/Staffan
?
-----Original Message-----
From: Christian Thalinger 
Sent: den 22 september 2010 2:38
To: Staffan Larsen
Cc: HYPERLINK "mailto:hotspot-dev at openjdk.java.net"hotspot-dev at openjdk.java.net
Subject: RE: Review request 6981484: Update development launcher
?
On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
? 

Thanks Christian - I obviously have some things to learn as a new
committer - didn't think about the copyrights :-)
??? 

?
Sure.? I was going the same route :-)
?
? 

?
http://cr.openjdk.java.net/~sla/6981484/webrev.02/
?
Now with updated copyrights.
??? 

?
As David already said.
?
-- Christian
?
? 

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100929/e91bd103/attachment.html 

From igor.veresov at oracle.com  Thu Sep 30 20:15:33 2010
From: igor.veresov at oracle.com (igor.veresov at oracle.com)
Date: Fri, 01 Oct 2010 03:15:33 +0000
Subject: hg: jdk7/hotspot/hotspot: 6988779: c1_LIRAssembler_x86.cpp crashes
	VS2010 compiler
Message-ID: <20101001031535.A9C2747E02@hg.openjdk.java.net>

Changeset: 5511edd5d719
Author:    iveresov
Date:      2010-09-30 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5511edd5d719

6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler
Summary: The workaround changes the scope of the variable
Reviewed-by: phh, ysr, kvn

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp