From Octavian.Tanase at Sun.COM  Mon Nov  3 14:43:18 2008
From: Octavian.Tanase at Sun.COM (Octavian Tanase)
Date: Mon, 03 Nov 2008 14:43:18 -0800
Subject: are you there?
Message-ID: <490F7E86.3090300@sun.com>




From Chris.Phillips at Sun.COM  Mon Nov  3 21:14:51 2008
From: Chris.Phillips at Sun.COM (Chris Phillips)
Date: Tue, 04 Nov 2008 00:14:51 -0500
Subject: are you there?
In-Reply-To: <490F7E86.3090300@sun.com>
References: <490F7E86.3090300@sun.com>
Message-ID: <490FDA4B.4030502@Sun.Com>

Hi Octavian

No  message so not sure whats needed...?
(If just to know if the list is functioning,
then this reply should suffice ;)

Cheers!
Chris

Octavian Tanase wrote:
> 


-- 
--
--     Woda: "Java: write once, debug anywhere" Hong Zhang
                      http://thehenrys.ca
  | Chris Phillips - Sun Java Sustaining JVM Engineer,             |
  | mailto:Chris.Phillips at Sun.Com               (416)483-3768      |
  | http://LGonQn.Org/www/Chris.Phillips  cell: (416)505-3610      |
  "EPIC stands for Expects Perfectly Intuitive Compilers" P. Bannon
                   http://www.hazmatmodine.com
  NOTICE:
  This email message is for the sole use of the intended recipient(s)
  and may contain confidential and privileged information.  Any
  unauthorized review, use, disclosure or distribution is prohibited.
  If you are not the intended recipient, please contact the sender by
  reply email and destroy all copies of the original message.
                    "blah blah blah - Ginger!"
--


From keith.mcguigan at sun.com  Wed Nov  5 09:43:37 2008
From: keith.mcguigan at sun.com (keith.mcguigan at sun.com)
Date: Wed, 05 Nov 2008 17:43:37 +0000
Subject: hg: jdk7/hotspot/hotspot: 2 new changesets
Message-ID: <20081105174344.420B6DE1D@hg.openjdk.java.net>

Changeset: c7ec737733a6
Author:    kamg
Date:      2008-10-30 15:48 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7ec737733a6

6756528: Bytecodes::special_length_at reads past end of code buffer
Summary: Add end-of-buffer indicator for paths used by the verifier
Reviewed-by: acorn, coleenp

! src/share/vm/interpreter/bytecodeStream.cpp
! src/share/vm/interpreter/bytecodes.cpp
! src/share/vm/interpreter/bytecodes.hpp

Changeset: 348be627a148
Author:    xlu
Date:      2008-10-31 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/348be627a148

Merge




From volker.simonis at gmail.com  Thu Nov  6 02:37:02 2008
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 6 Nov 2008 11:37:02 +0100
Subject: Why do we need StubRoutines::handler_for_unsafe_access()?
Message-ID: <d65861880811060237q2321e96xe82575cb33744be0@mail.gmail.com>

Hi,

does anybody know why we need the stub routine
"handler_for_unsafe_access". As far as I can see, the stub routine
only calls "handle_unsafe_access()" (which is defined in
"stubGenerator_<arch>.cpp) and jumps to the returned address.

"handle_unsafe_access()" in turn calls
"thread->set_pending_unsafe_access_error()" to request an asynchronous
exception and returns the next PC which is calculated based on the
previously saved exception PC ("thread->saved_exception_pc()").

The only place where the "handler_for_unsafe_access" stub is called is
in the signal handler, if a bus error happens during an unsafe
operation. My question is if it is really necessary to go through a
stub? From my point of view it would be much easier to call
"thread->set_pending_unsafe_access_error()" right from the signal
handler, compute the next PC and return from the signal handler right
to that PC. Are there any objectives why this wouldn't work?

Thank you and best regards,
Volker


From John.Rose at Sun.COM  Thu Nov  6 15:44:34 2008
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 06 Nov 2008 15:44:34 -0800
Subject: Why do we need StubRoutines::handler_for_unsafe_access()?
In-Reply-To: <d65861880811060237q2321e96xe82575cb33744be0@mail.gmail.com>
References: <d65861880811060237q2321e96xe82575cb33744be0@mail.gmail.com>
Message-ID: <B2C26DF2-A24A-412C-91B0-78AB90059688@sun.com>

On Nov 6, 2008, at 2:37 AM, Volker Simonis wrote:

> From my point of view it would be much easier to call
> "thread->set_pending_unsafe_access_error()" right from the signal
> handler, compute the next PC and return from the signal handler right
> to that PC. Are there any objectives why this wouldn't work?

I think it would probably work.  The detour through  
handle_unsafe_access is there simply to move work outside of the  
signal handler.  Probably it is simple enough to push all the work  
into the signal handler as it stands.  The risk of putting more logic  
into the signal handler is that eventually somebody will add a path  
to an innocent looking subroutine that is called by the signal  
handler, and the path will be incompatible with execution in the  
signal handler.  Note, for example, that the signal handler uses  
ThreadLocalStorage::get_thread_slow, whereas most of the JVM code  
uses faster methods.  But if you accidentally do a get-thread  
operation from within the signal handler, you may crash the JVM.

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

From john.coomes at sun.com  Fri Nov  7 14:11:14 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 07 Nov 2008 22:11:14 +0000
Subject: hg: jdk7/hotspot: Added tag jdk7-b39 for changeset ab523b49de1f
Message-ID: <20081107221115.21142DFB1@hg.openjdk.java.net>

Changeset: 44be42de6693
Author:    xdono
Date:      2008-11-06 12:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/rev/44be42de6693

Added tag jdk7-b39 for changeset ab523b49de1f

! .hgtags



From john.coomes at sun.com  Fri Nov  7 14:12:45 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 07 Nov 2008 22:12:45 +0000
Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b39 for changeset 55078b6661e2
Message-ID: <20081107221246.D99B1DFB6@hg.openjdk.java.net>

Changeset: 184e21992f47
Author:    xdono
Date:      2008-11-06 12:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/184e21992f47

Added tag jdk7-b39 for changeset 55078b6661e2

! .hgtags



From john.coomes at sun.com  Fri Nov  7 14:16:08 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 07 Nov 2008 22:16:08 +0000
Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b39 for changeset 831b80be6cea
Message-ID: <20081107221610.83B5EDFBF@hg.openjdk.java.net>

Changeset: 54946f466e2c
Author:    xdono
Date:      2008-11-06 12:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/54946f466e2c

Added tag jdk7-b39 for changeset 831b80be6cea

! .hgtags



From john.coomes at sun.com  Fri Nov  7 14:17:42 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 07 Nov 2008 22:17:42 +0000
Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b39 for changeset 077bc9b1b035
Message-ID: <20081107221744.D2574DFC6@hg.openjdk.java.net>

Changeset: 70a6ac6dd737
Author:    xdono
Date:      2008-11-06 12:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/70a6ac6dd737

Added tag jdk7-b39 for changeset 077bc9b1b035

! .hgtags



From john.coomes at sun.com  Fri Nov  7 14:19:38 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 07 Nov 2008 22:19:38 +0000
Subject: hg: jdk7/hotspot/jdk: Added tag jdk7-b39 for changeset 4e51997582ef
Message-ID: <20081107222017.A76FBDFCF@hg.openjdk.java.net>

Changeset: 2914c04c8644
Author:    xdono
Date:      2008-11-06 12:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2914c04c8644

Added tag jdk7-b39 for changeset 4e51997582ef

! .hgtags



From john.coomes at sun.com  Fri Nov  7 14:23:52 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 07 Nov 2008 22:23:52 +0000
Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b39 for changeset
	3fb51e47622b
Message-ID: <20081107222356.06880DFD4@hg.openjdk.java.net>

Changeset: 968ca53217a1
Author:    xdono
Date:      2008-11-06 12:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/968ca53217a1

Added tag jdk7-b39 for changeset 3fb51e47622b

! .hgtags



From twisti at complang.tuwien.ac.at  Mon Nov 10 13:34:11 2008
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Mon, 10 Nov 2008 22:34:11 +0100
Subject: hotspot/make/solaris/makefiles/sparcWorks.make misses 64-bit flags
	with Sun Studio 5.10
Message-ID: <1226352851.989.10.camel@localhost.localdomain>

Hi!

I'm having some linking problems when building HotSpot for i386 with Sun
Studio 5.10 (but that will be the subject of another mail), so I tried
to build the 64-bit version.  I noticed that the -m64 switch is missing
and 32-bit object are generated.  A little digging into the Makefiles
revealed this line in hotspot/make/solaris/makefiles/sparcWorks.make:

# Select the ARCHFLAGs and other SS12 (5.9) options
ifeq ($(shell expr $(COMPILER_REV) \>= 5.9), 1)

Executing this line with 5.10 gives:

$ expr "5.10" \>= "5.9"
0

Very true, as 5.1 is obviously less than 5.9.  I don't have a patch for
this one ready as I'm not sure what the appropriate fix is (fixing only
this check or doing something like COMPILER_REV_MAJOR,
COMPILER_REV_MINOR).  What would be the appropriate fix?

- Christian



From Xiaobin.Lu at Sun.COM  Mon Nov 10 13:48:04 2008
From: Xiaobin.Lu at Sun.COM (Xiaobin Lu)
Date: Mon, 10 Nov 2008 13:48:04 -0800
Subject: hotspot/make/solaris/makefiles/sparcWorks.make misses 64-bit flags
	with Sun Studio 5.10
In-Reply-To: <1226352851.989.10.camel@localhost.localdomain>
References: <1226352851.989.10.camel@localhost.localdomain>
Message-ID: <4918AC14.2040400@Sun.COM>

I think the right fix is to compare COMPILER_REV_MAJOR and 
COMPILER_REV_MINOR one by one just like what we do to Linux kernel 
version somewhere in the make directory.

-Xiaobin

Christian Thalinger wrote:
> Hi!
>
> I'm having some linking problems when building HotSpot for i386 with Sun
> Studio 5.10 (but that will be the subject of another mail), so I tried
> to build the 64-bit version.  I noticed that the -m64 switch is missing
> and 32-bit object are generated.  A little digging into the Makefiles
> revealed this line in hotspot/make/solaris/makefiles/sparcWorks.make:
>
> # Select the ARCHFLAGs and other SS12 (5.9) options
> ifeq ($(shell expr $(COMPILER_REV) \>= 5.9), 1)
>
> Executing this line with 5.10 gives:
>
> $ expr "5.10" \>= "5.9"
> 0
>
> Very true, as 5.1 is obviously less than 5.9.  I don't have a patch for
> this one ready as I'm not sure what the appropriate fix is (fixing only
> this check or doing something like COMPILER_REV_MAJOR,
> COMPILER_REV_MINOR).  What would be the appropriate fix?
>
> - Christian
>
>   



From Vladimir.Kozlov at Sun.COM  Mon Nov 10 14:08:02 2008
From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov)
Date: Mon, 10 Nov 2008 14:08:02 -0800
Subject: hotspot/make/solaris/makefiles/sparcWorks.make misses 64-bit flags
	with Sun Studio 5.10
In-Reply-To: <4918AC14.2040400@Sun.COM>
References: <1226352851.989.10.camel@localhost.localdomain>
	<4918AC14.2040400@Sun.COM>
Message-ID: <4918B0C2.40504@sun.com>

I agree with Xiaobin.

Christian, thank you for looking on this.
But you should understand that we are not supporting 5.10
compilers yet. We just switched to 5.9 for HS14(jdk7) and jdk6
uses 5.8 (I don't know what OpenJDK6 is using).
So it will be few years before we move to 5.10, I think.

I would suggest to use 5.9 for your work if you have
access to it.

Thanks,
Vladimir

Xiaobin Lu wrote:
> I think the right fix is to compare COMPILER_REV_MAJOR and 
> COMPILER_REV_MINOR one by one just like what we do to Linux kernel 
> version somewhere in the make directory.
> 
> -Xiaobin
> 
> Christian Thalinger wrote:
>> Hi!
>>
>> I'm having some linking problems when building HotSpot for i386 with Sun
>> Studio 5.10 (but that will be the subject of another mail), so I tried
>> to build the 64-bit version.  I noticed that the -m64 switch is missing
>> and 32-bit object are generated.  A little digging into the Makefiles
>> revealed this line in hotspot/make/solaris/makefiles/sparcWorks.make:
>>
>> # Select the ARCHFLAGs and other SS12 (5.9) options
>> ifeq ($(shell expr $(COMPILER_REV) \>= 5.9), 1)
>>
>> Executing this line with 5.10 gives:
>>
>> $ expr "5.10" \>= "5.9"
>> 0
>>
>> Very true, as 5.1 is obviously less than 5.9.  I don't have a patch for
>> this one ready as I'm not sure what the appropriate fix is (fixing only
>> this check or doing something like COMPILER_REV_MAJOR,
>> COMPILER_REV_MINOR).  What would be the appropriate fix?
>>
>> - Christian
>>
>>   
> 


From twisti at complang.tuwien.ac.at  Mon Nov 10 14:12:01 2008
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Mon, 10 Nov 2008 23:12:01 +0100
Subject: hotspot/make/solaris/makefiles/sparcWorks.make misses 64-bit
	flags with Sun Studio 5.10
In-Reply-To: <4918B0C2.40504@sun.com>
References: <1226352851.989.10.camel@localhost.localdomain>
	<4918AC14.2040400@Sun.COM>  <4918B0C2.40504@sun.com>
Message-ID: <1226355121.989.14.camel@localhost.localdomain>

On Mon, 2008-11-10 at 14:08 -0800, Vladimir Kozlov wrote:
> I agree with Xiaobin.
> 
> Christian, thank you for looking on this.
> But you should understand that we are not supporting 5.10
> compilers yet. We just switched to 5.9 for HS14(jdk7) and jdk6
> uses 5.8 (I don't know what OpenJDK6 is using).
> So it will be few years before we move to 5.10, I think.

I see.

> 
> I would suggest to use 5.9 for your work if you have
> access to it.

Yeah, it's a pity OpenSolaris updates everything without asking.  I'll
try if I can downgrade.

- Christian



From volker.simonis at gmail.com  Tue Nov 11 02:23:50 2008
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 11 Nov 2008 11:23:50 +0100
Subject: Verification failure in SPECJVM2008.scimark.fft.small on
	Windows/32bit
In-Reply-To: <d65861880810301639i4f3f82c2m2bc70aad6360c57d@mail.gmail.com>
References: <d65861880810291155l667237bah13854b9a40fdc443@mail.gmail.com>
	<27F53E5C-6F69-49A3-A7D8-443ED4F35060@sun.com>
	<d65861880810301122g66fffaeqda0e267b63cb81fe@mail.gmail.com>
	<57B328E3-C3EA-4F57-A284-799C01ED5F93@Sun.COM>
	<d65861880810301639i4f3f82c2m2bc70aad6360c57d@mail.gmail.com>
Message-ID: <d65861880811110223x58642861t37791910dd474f02@mail.gmail.com>

Hi,

unfortunately I had no success in finding a solution for this problem.
I have therefore opened a bug report (" Floating point failure in
32-bit JDK 6/7 on multicore Windows with -XX:UseSSE=2"  with the
internal review ID 1389916).

I think this is quite a serious problem and it would be nice, if
somebody could have a look on it.

Thank you and best regards,
Volker

PS: with the option "-XX:+TraceRuntimeCalls" I could see that the
benchmark calls "SharedRuntime::dsin(jdouble x)" quite often. The
problem is probably also not related to any kind of OnStackReplacement
or Deoptimization (I checked with "-XX:+TraceOnStackReplacement" and
"-XX:+TraceDeoptimization) because the offending methods are compiled
quite some time before the actual failure happens.



On 10/31/08, Volker Simonis <volker.simonis at gmail.com> wrote:
> Funny enough, my previous problem, which was caused by an uncleared FP
>  status register, only happend on 64-bit Windows and only with MSVC
>  2005 and 2008 while this problem happens only on 32-bit Windows and
>  with MSVC 2005 (the one we use for our builds) as well as with older
>  versions of MSVC (i.e. the one that is used for the official Java 7
>  buildss by SUN).
>
>  I finally found some documentation about the calling conventions on
>  Windows/x64 and it states: "A callee that modifies any of the fields
>  within FPCSR/MXCSR must restore them before returning to its caller.
>  Furthermore, a caller that has modified any of these fields must
>  restore them to their standard values before invoking a callee unless
>  by agreement the callee expects the modified values". I could however
>  only find this information for MSVC 2005 and 2008 (see
>  http://msdn.microsoft.com/en-us/library/ms235300(VS.80).aspx and
>  http://msdn.microsoft.com/en-us/library/ms235300.aspx) and I think you
>  use an older version for Windows builds, right?
>
>
>  Volker
>
>
>  On 10/30/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
>  > I haven't had a chance to investigate yet, but I wonder if this is related
>  > to the MXCSR issue you had mentioned previously?  AlwaysRestoreFPU doesn't
>  > deal with the MXCSR. -XX:+RestoreMXCSROnJNICalls does something similar
>  > though.
>  >
>  >  tom
>  >
>  >
>  >  On Oct 30, 2008, at 11:22 AM, Volker Simonis wrote:
>  >
>  >
>  > > Hi Tom,
>  > >
>  > > I ran the benchmark all day and I couldn't reproduce the problem
>  > > neither with -XX:UseSSE=0 nor with -XX:UseSSE=1 although I havent done
>  > > that many runs with -XX:UseSSE=1 like with -XX:UseSSE=0. It seems the
>  > > problem only shows up with -XX:UseSSE=2 or higher. I'll start a run
>  > > with "-XX:UseSSE=2 -XX:+CheckJNICalls" now and post the results
>  > > tomorrow. I have also found some other options which may be worth
>  > > trying them out: -XX:+AlwaysRestoreFPU and -XX:+VerifyFPU where the
>  > > last one is only available in the debug build.
>  > >
>  > > I've noticed that the tests uses a java.lang.ThreadLocal double array
>  > > to store and compute the values. May this be a problem perhaps?
>  > >
>  > > Did you had a chance to reproduce the problem?
>  > >
>  > > Regards,
>  > > Volker
>  > >
>  > > On 10/29/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
>  > >
>  > > > I haven't seen this before, though I pretty much never benchmark on
>  > windows.
>  > > > Is the use of -XX:+CITime required? have you tried debug builds?  Does
>  > it
>  > > > reproduce with -XX:UseSSE=0?  It might be interesting to run with
>  > > > -XX:+CheckJNICalls which will verify the various fp control words have
>  > the
>  > > > right value.  I'll see if I can reproduce it here.
>  > > >
>  > > > tom
>  > > >
>  > > >
>  > > > On Oct 29, 2008, at 11:55 AM, Volker Simonis wrote:
>  > > >
>  > > >
>  > > >
>  > > > > Hi,
>  > > > >
>  > > > > we have problems with SPECJVM2008 on Windows/x86 machines with at
>  > > > > least 4 cores and at least 4 benchmark threads. The benchmark
>  > > > > reproducible fails in the result verification of the sub-benchmark
>  > > > > scimark.fft.small (however in random places).
>  > > > >
>  > > > > We could reproduce the problem with JDK 6u7 and 6u10 as well as with
>  > > > > the latest JDK 7b38 however only for the 32-bit Windows versions.
>  > > > >
>  > > > > Because the problem occurs with both, C1 and C2 and because the
>  > > > > problem isn't reproducible neither with  -Xint, nor with the 64-bit
>  > > > > Windows or the Linux JDK, we think that this may be a problem in the
>  > > > > HotSpot runtime (perhaps a timing/concurrency problem with the
>  > > > > handling of 64-bit doubles in a 32-bit JDK on multi core machines?),
>  > > > > but this is only a wild guess.
>  > > > >
>  > > > > We also observed that all the files (JDK, test classes and result
>  > > > > files) had to be on the local host in order to reproduce the problem
>  > > > > and we had the impression that the benchmark fails more quickly on
>  > > > > Intel XEON, compared to AMD Opteron (we tested on the following
>  > > > > hardware: Intel (2x XEON (with HT), 3.4GHz, 8GB, MS Win Server 2003
>  > > > > Enterprise x64, SP1) and AMD (4x Opteron 270, 2.0GHz, 9GB, MS Win
>  > > > > Server 2003 Enterprise x64, SP1)).
>  > > > >
>  > > > > Has anybody else already observed this problem? Is this perhaps an
>  > > > > issue of SPECJVM2008.scimark.fft.small?
>  > > > >
>  > > > > Any comments would be highly appreciated!
>  > > > >
>  > > > > Regards,
>  > > > > Volker
>  > > > >
>  > > > > PS: JVM2008 is available from
>  > > > >
>  > > > http://www.spec.org/download.html
>  > > >
>  > > > >
>  > > > > PPS: here's the command line we used for the tests: java -server
>  > > > > -XX:+CITime -Djava.io.tmpdir=tmp -jar SPECjvm2008.jar -ikv -wt 30 -it
>  > > > > 60 -bt 4 --base scimark.fft.small scimark.fft.small scimark.fft.small
>  > > > > scimark.fft.small scimark.fft.small scimark.fft.small
>  > > > > scimark.fft.small scimark.fft.small scimark.fft.small
>  > > > > scimark.fft.small scimark.fft.small scimark.fft.small
>  > > > > scimark.fft.small scimark.fft.small scimark.fft.small
>  > > > > scimark.fft.small scimark.fft.small scimark.fft.small
>  > > > > scimark.fft.small scimark.fft.small
>  > > > >
>  > > > >
>  > > >
>  > > >
>  > > >
>  > >
>  >
>  >
>


From Erik.Trimble at Sun.COM  Tue Nov 11 03:08:06 2008
From: Erik.Trimble at Sun.COM (Erik Trimble)
Date: Tue, 11 Nov 2008 03:08:06 -0800
Subject: hotspot/make/solaris/makefiles/sparcWorks.make misses 64-bit flags
	with Sun Studio 5.10
In-Reply-To: <1226355121.989.14.camel@localhost.localdomain>
References: <1226352851.989.10.camel@localhost.localdomain>
	<4918AC14.2040400@Sun.COM> <4918B0C2.40504@sun.com>
	<1226355121.989.14.camel@localhost.localdomain>
Message-ID: <49196796.1080605@sun.com>

Christian Thalinger wrote:
> On Mon, 2008-11-10 at 14:08 -0800, Vladimir Kozlov wrote:
>   
>> I agree with Xiaobin.
>>
>> Christian, thank you for looking on this.
>> But you should understand that we are not supporting 5.10
>> compilers yet. We just switched to 5.9 for HS14(jdk7) and jdk6
>> uses 5.8 (I don't know what OpenJDK6 is using).
>> So it will be few years before we move to 5.10, I think.
>>     
>
> I see.
>
>   
>> I would suggest to use 5.9 for your work if you have
>> access to it.
>>     
>
> Yeah, it's a pity OpenSolaris updates everything without asking.  I'll
> try if I can downgrade.
>
> - Christian
>
>   
Not to be quite as pessimistic as Vladimir, I expect that we will update 
to the 5.10 compilers shortly after Sun Studio 13 GAs.   That is, likely 
2-3 months afterwards.

Now, I can't do anything other than guess when SS13 will be out.  
Sometime in the first half of 2009, maybe?

-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA



From Thomas.Rodriguez at Sun.COM  Tue Nov 11 09:19:47 2008
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Tue, 11 Nov 2008 09:19:47 -0800
Subject: Verification failure in SPECJVM2008.scimark.fft.small on
	Windows/32bit
In-Reply-To: <d65861880811110223x58642861t37791910dd474f02@mail.gmail.com>
References: <d65861880810291155l667237bah13854b9a40fdc443@mail.gmail.com>
	<27F53E5C-6F69-49A3-A7D8-443ED4F35060@sun.com>
	<d65861880810301122g66fffaeqda0e267b63cb81fe@mail.gmail.com>
	<57B328E3-C3EA-4F57-A284-799C01ED5F93@Sun.COM>
	<d65861880810301639i4f3f82c2m2bc70aad6360c57d@mail.gmail.com>
	<d65861880811110223x58642861t37791910dd474f02@mail.gmail.com>
Message-ID: <A238BBED-6382-41E9-9A41-79B28518E3CA@Sun.COM>

I tried reproducing this without luck though I couldn't find many  
machines with the right configuration. I'll try to find a machine that  
reproduces this.  Thanks for the report.

tom

On Nov 11, 2008, at 2:23 AM, Volker Simonis wrote:

> Hi,
>
> unfortunately I had no success in finding a solution for this problem.
> I have therefore opened a bug report (" Floating point failure in
> 32-bit JDK 6/7 on multicore Windows with -XX:UseSSE=2"  with the
> internal review ID 1389916).
>
> I think this is quite a serious problem and it would be nice, if
> somebody could have a look on it.
>
> Thank you and best regards,
> Volker
>
> PS: with the option "-XX:+TraceRuntimeCalls" I could see that the
> benchmark calls "SharedRuntime::dsin(jdouble x)" quite often. The
> problem is probably also not related to any kind of OnStackReplacement
> or Deoptimization (I checked with "-XX:+TraceOnStackReplacement" and
> "-XX:+TraceDeoptimization) because the offending methods are compiled
> quite some time before the actual failure happens.
>
>
>
> On 10/31/08, Volker Simonis <volker.simonis at gmail.com> wrote:
>> Funny enough, my previous problem, which was caused by an uncleared  
>> FP
>> status register, only happend on 64-bit Windows and only with MSVC
>> 2005 and 2008 while this problem happens only on 32-bit Windows and
>> with MSVC 2005 (the one we use for our builds) as well as with older
>> versions of MSVC (i.e. the one that is used for the official Java 7
>> buildss by SUN).
>>
>> I finally found some documentation about the calling conventions on
>> Windows/x64 and it states: "A callee that modifies any of the fields
>> within FPCSR/MXCSR must restore them before returning to its caller.
>> Furthermore, a caller that has modified any of these fields must
>> restore them to their standard values before invoking a callee unless
>> by agreement the callee expects the modified values". I could however
>> only find this information for MSVC 2005 and 2008 (see
>> http://msdn.microsoft.com/en-us/library/ms235300(VS.80).aspx and
>> http://msdn.microsoft.com/en-us/library/ms235300.aspx) and I think  
>> you
>> use an older version for Windows builds, right?
>>
>>
>> Volker
>>
>>
>> On 10/30/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
>>> I haven't had a chance to investigate yet, but I wonder if this is  
>>> related
>>> to the MXCSR issue you had mentioned previously?  AlwaysRestoreFPU  
>>> doesn't
>>> deal with the MXCSR. -XX:+RestoreMXCSROnJNICalls does something  
>>> similar
>>> though.
>>>
>>> tom
>>>
>>>
>>> On Oct 30, 2008, at 11:22 AM, Volker Simonis wrote:
>>>
>>>
>>>> Hi Tom,
>>>>
>>>> I ran the benchmark all day and I couldn't reproduce the problem
>>>> neither with -XX:UseSSE=0 nor with -XX:UseSSE=1 although I havent  
>>>> done
>>>> that many runs with -XX:UseSSE=1 like with -XX:UseSSE=0. It seems  
>>>> the
>>>> problem only shows up with -XX:UseSSE=2 or higher. I'll start a run
>>>> with "-XX:UseSSE=2 -XX:+CheckJNICalls" now and post the results
>>>> tomorrow. I have also found some other options which may be worth
>>>> trying them out: -XX:+AlwaysRestoreFPU and -XX:+VerifyFPU where the
>>>> last one is only available in the debug build.
>>>>
>>>> I've noticed that the tests uses a java.lang.ThreadLocal double  
>>>> array
>>>> to store and compute the values. May this be a problem perhaps?
>>>>
>>>> Did you had a chance to reproduce the problem?
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>> On 10/29/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
>>>>
>>>>> I haven't seen this before, though I pretty much never benchmark  
>>>>> on
>>> windows.
>>>>> Is the use of -XX:+CITime required? have you tried debug  
>>>>> builds?  Does
>>> it
>>>>> reproduce with -XX:UseSSE=0?  It might be interesting to run with
>>>>> -XX:+CheckJNICalls which will verify the various fp control  
>>>>> words have
>>> the
>>>>> right value.  I'll see if I can reproduce it here.
>>>>>
>>>>> tom
>>>>>
>>>>>
>>>>> On Oct 29, 2008, at 11:55 AM, Volker Simonis wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> we have problems with SPECJVM2008 on Windows/x86 machines with at
>>>>>> least 4 cores and at least 4 benchmark threads. The benchmark
>>>>>> reproducible fails in the result verification of the sub- 
>>>>>> benchmark
>>>>>> scimark.fft.small (however in random places).
>>>>>>
>>>>>> We could reproduce the problem with JDK 6u7 and 6u10 as well as  
>>>>>> with
>>>>>> the latest JDK 7b38 however only for the 32-bit Windows versions.
>>>>>>
>>>>>> Because the problem occurs with both, C1 and C2 and because the
>>>>>> problem isn't reproducible neither with  -Xint, nor with the 64- 
>>>>>> bit
>>>>>> Windows or the Linux JDK, we think that this may be a problem  
>>>>>> in the
>>>>>> HotSpot runtime (perhaps a timing/concurrency problem with the
>>>>>> handling of 64-bit doubles in a 32-bit JDK on multi core  
>>>>>> machines?),
>>>>>> but this is only a wild guess.
>>>>>>
>>>>>> We also observed that all the files (JDK, test classes and result
>>>>>> files) had to be on the local host in order to reproduce the  
>>>>>> problem
>>>>>> and we had the impression that the benchmark fails more quickly  
>>>>>> on
>>>>>> Intel XEON, compared to AMD Opteron (we tested on the following
>>>>>> hardware: Intel (2x XEON (with HT), 3.4GHz, 8GB, MS Win Server  
>>>>>> 2003
>>>>>> Enterprise x64, SP1) and AMD (4x Opteron 270, 2.0GHz, 9GB, MS Win
>>>>>> Server 2003 Enterprise x64, SP1)).
>>>>>>
>>>>>> Has anybody else already observed this problem? Is this perhaps  
>>>>>> an
>>>>>> issue of SPECJVM2008.scimark.fft.small?
>>>>>>
>>>>>> Any comments would be highly appreciated!
>>>>>>
>>>>>> Regards,
>>>>>> Volker
>>>>>>
>>>>>> PS: JVM2008 is available from
>>>>>>
>>>>> http://www.spec.org/download.html
>>>>>
>>>>>>
>>>>>> PPS: here's the command line we used for the tests: java -server
>>>>>> -XX:+CITime -Djava.io.tmpdir=tmp -jar SPECjvm2008.jar -ikv -wt  
>>>>>> 30 -it
>>>>>> 60 -bt 4 --base scimark.fft.small scimark.fft.small  
>>>>>> scimark.fft.small
>>>>>> scimark.fft.small scimark.fft.small scimark.fft.small
>>>>>> scimark.fft.small scimark.fft.small scimark.fft.small
>>>>>> scimark.fft.small scimark.fft.small scimark.fft.small
>>>>>> scimark.fft.small scimark.fft.small scimark.fft.small
>>>>>> scimark.fft.small scimark.fft.small scimark.fft.small
>>>>>> scimark.fft.small scimark.fft.small
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>



From vladimir.kozlov at sun.com  Tue Nov 11 21:44:18 2008
From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com)
Date: Wed, 12 Nov 2008 05:44:18 +0000
Subject: hg: jdk7/hotspot/hotspot: 7 new changesets
Message-ID: <20081112054434.B350AD22B@hg.openjdk.java.net>

Changeset: 4d9884b01ba6
Author:    never
Date:      2008-10-28 09:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4d9884b01ba6

6754519: don't emit flag fixup for NaN when condition being tested doesn't need it
Reviewed-by: kvn, rasbold

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/adlparse.hpp
! src/share/vm/adlc/filebuff.cpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/reg_split.cpp

Changeset: b6cfd754403d
Author:    never
Date:      2008-10-28 18:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b6cfd754403d

6649622: HotSpot Biased locking needs tuning on latest CPUs
Reviewed-by: rasbold, kvn, kamg

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

Changeset: f4fe12e429a4
Author:    never
Date:      2008-10-30 17:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f4fe12e429a4

6764622: IdealGraphVisualizer fixes
Reviewed-by: rasbold, jrose

! src/share/tools/IdealGraphVisualizer/Bytecodes/src/com/sun/hotspot/igv/bytecodes/BytecodeViewTopComponent.java
! src/share/tools/IdealGraphVisualizer/ControlFlow/src/com/sun/hotspot/igv/controlflow/ControlFlowScene.java
! src/share/tools/IdealGraphVisualizer/ControlFlow/src/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.java
! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/FolderNode.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/GraphDocument.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/Group.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputGraph.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputMethod.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputNode.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/Properties.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/Property.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Parser.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Printer.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLParser.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLWriter.java
! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java
! src/share/tools/IdealGraphVisualizer/Filter/manifest.mf
! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java
! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/SplitFilter.java
! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Diagram.java
! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Figure.java
! src/share/tools/IdealGraphVisualizer/HierarchicalLayout/src/com/sun/hotspot/igv/hierarchicallayout/Graph.java
! src/share/tools/IdealGraphVisualizer/HierarchicalLayout/src/com/sun/hotspot/igv/hierarchicallayout/HierarchicalClusterLayoutManager.java
! src/share/tools/IdealGraphVisualizer/Layout/src/com/sun/hotspot/igv/layout/LayoutGraph.java
! src/share/tools/IdealGraphVisualizer/README
! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/PropertiesSheet.java
! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/RangeSliderModel.java
! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramScene.java
! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramViewModel.java
! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/FindPanel.java
! src/share/tools/IdealGraphVisualizer/nbproject/platform.properties
! src/share/tools/IdealGraphVisualizer/nbproject/project.properties
! src/share/vm/adlc/output_h.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/runtime/frame.cpp

Changeset: 72c5366e5d86
Author:    rasbold
Date:      2008-11-06 14:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/72c5366e5d86

6743900: frequency based block layout
Summary: post-register allocation pass that drives block layout by edge frequencies
Reviewed-by: never, kvn

! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/phase.cpp
! src/share/vm/opto/phase.hpp

Changeset: 0bf25c4807f9
Author:    never
Date:      2008-11-06 20:00 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0bf25c4807f9

6761594: framesize rounding code rounds using wrong units leading to slightly oversized frames
Reviewed-by: rasbold, kvn

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

Changeset: a1980da045cc
Author:    kvn
Date:      2008-11-07 09:29 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a1980da045cc

6462850: generate biased locking code in C2 ideal graph
Summary: Inline biased locking code in C2 ideal graph during macro nodes expansion
Reviewed-by: never

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os_cpu/linux_x86/vm/linux_x86_32.ad
! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 577f3a2e0662
Author:    never
Date:      2008-11-07 13:55 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/577f3a2e0662

Merge




From keith.mcguigan at sun.com  Wed Nov 12 12:31:34 2008
From: keith.mcguigan at sun.com (keith.mcguigan at sun.com)
Date: Wed, 12 Nov 2008 20:31:34 +0000
Subject: hg: jdk7/hotspot/hotspot: 2 new changesets
Message-ID: <20081112203140.CDB94D2F7@hg.openjdk.java.net>

Changeset: 05db98ed59ba
Author:    coleenp
Date:      2008-11-07 11:03 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/05db98ed59ba

6760773: UseCompressedOops is broken with UseParNewGC
Summary: sparc code for gen_subtype_check was doing an ld for a compressed oop with the sign bit set so not comparing, leading to a ClassCastException.
Reviewed-by: phh, never, acorn, kvn, xlu

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

Changeset: 909cfd030fab
Author:    kamg
Date:      2008-11-12 11:23 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/909cfd030fab

Merge




From Xiaobin.Lu at Sun.COM  Wed Nov 12 20:39:27 2008
From: Xiaobin.Lu at Sun.COM (Xiaobin Lu)
Date: Wed, 12 Nov 2008 20:39:27 -0800
Subject: review request for 6554406
Message-ID: <491BAF7F.1090607@Sun.COm>

Webrev: http://webrev.invokedynamic.info/xiaobin.lu/65544606/
(I have sent out the request before, but it was last year due to the 
long delay from library team about getting JAT approved about this).

Details:

6554406:  Change switch UseVMInterruptibleIO default to false (sol)

This is one of the last steps toward completing CR 4385444 "(spec) 
InterruptedIOException should not be required by platform specification 
(sol)" to get rid of Solaris-specific behavior with respect to thread 
interruption. (Note that this is unrelated to java.nio's fully portable 
support for I/O interruptibility).

This change flips the VM interruptible I/O switch "UseVMInterruptibleIO" 
to false by default for JDK 7 or later. In the meantime, we need to keep 
the default value to be true for JDK 6 (and any update releases) by 
default. To make it a bit more general, I came up with a method (see 
Flag::adjust_jdk_version_dependent_flag) to make such change easier in 
the future.

A CCC request regarding this change has been finalized and I am waiting 
to get it approved.

Reviewed by:
Verified by:
JPRT
(also run inside the dbx to verify the flag value change the way we 
expected.)

Thanks,
-Xiaobin




From wimmer at ssw.jku.at  Thu Nov 13 21:06:11 2008
From: wimmer at ssw.jku.at (Christian Wimmer)
Date: Thu, 13 Nov 2008 21:06:11 -0800
Subject: HotSpot build problems on Windows
Message-ID: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>

Hi

When building the HotSpot VM on Windows using the create-script that  
generates the Visual Studio project files, a bunch of problems occur.  
I use Visual Studio 2008 on 64-bit Windows Vista, but most things are  
independent of this configuration. Most problems seem to be related to  
the recent integration of the G1 garbage collector.

1) The most sever problem is that create.bat stops with the error  
message "command line too long" when executing MakeDeps. The tool  
takes so many parameters to configure the file structure for the VS  
project. The integration of G1 added some new ones, so now the line is  
too long. Even putting the source code directly into  C:\ so that  
absolute paths are as short as possible does not help. My solution is  
to abbreviate some command line flags, like "-additionalFile" and "- 
additionalGeneratedFile". This works, but is no general solution for  
the future.

2) duplicate files: the files "concurrentGCThread.cpp" and  
"concurrentGCThread.hpp" are present in two directories:  
"gc_implementation\concurrentMarkSweep" and "gc_implementation 
\shared". The content of the files is equal, so just deleting one pair  
of files works.

3) Missing includeDB reference for G1: In the file "make\windows 
\projectfiles\common\Makefile", the reference of "includeDB_gc_g1" is  
missing in the definition of "IncludeDBs_gc"

4) The macro HOTSPOT_LIB_ARCH is not defined, i.e. the following line  
is missing in the file "make\windows\makefiles\makedeps.make":
	-define HOTSPOT_LIB_ARCH=\\\"$(BUILDARCH)\\\" \

5) In the same file, the following define is necessary to avoid build  
errors starting with Visual Studio 2005:
	-define _CRT_SECURE_NO_WARNINGS \

VS2008 also has a different project file format, however importing the  
currently generated project files works fine so this is only a minor  
issue.


Christian


From Jon.Masamitsu at Sun.COM  Fri Nov 14 08:34:50 2008
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 14 Nov 2008 08:34:50 -0800
Subject: HotSpot build problems on Windows
In-Reply-To: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>
References: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>
Message-ID: <491DA8AA.4050303@sun.com>

As Christian has found we have in a repository

./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
./share/vm/gc_implementation/shared/concurrentGCThread.cpp

The files are the same now.   I'm guessing that we
should delete

./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp

I'll see if I can tell mercurial to do that.  Any concerns?  Were there any
thoughts that concurrentGCThread.cpp should be split between
CMS and shared (i.e., that there is some code in concurrentGCThread.cpp
specialized for CMS)?



Christian Wimmer wrote On 11/13/08 21:06,:

>...
>2) duplicate files: the files "concurrentGCThread.cpp" and  
>"concurrentGCThread.hpp" are present in two directories:  
>"gc_implementation\concurrentMarkSweep" and "gc_implementation 
>\shared". The content of the files is equal, so just deleting one pair  
>of files works.
>
>
>  
>



From Y.S.Ramakrishna at Sun.COM  Fri Nov 14 09:19:05 2008
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Fri, 14 Nov 2008 09:19:05 -0800
Subject: HotSpot build problems on Windows
In-Reply-To: <491DA8AA.4050303@sun.com>
References: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>
	<491DA8AA.4050303@sun.com>
Message-ID: <f897de157a86.491d4289@sun.com>


Apologies! (mea culpa I am guessing.)

Yes, the version(s) under concurrentMarkSweep should go away.
I don't believe there's any CMS-specific
code in there, so no need to split (at the moment at least).

As Christian pointed out there's a .cpp as well as a .hpp that have
to go. Then you may want to scan the includeDB's and shuffle include's
around if/as needed.

-- ramki

----- Original Message -----
From: Jon Masamitsu <Jon.Masamitsu at Sun.COM>
Date: Friday, November 14, 2008 8:35 am
Subject: Re: HotSpot build problems on Windows
To: Christian Wimmer <wimmer at ssw.jku.at>
Cc: hotspot-dev at openjdk.java.net


> As Christian has found we have in a repository
> 
> ./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
> ./share/vm/gc_implementation/shared/concurrentGCThread.cpp
> 
> The files are the same now.   I'm guessing that we
> should delete
> 
> ./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
> 
> I'll see if I can tell mercurial to do that.  Any concerns?  Were 
> there any
> thoughts that concurrentGCThread.cpp should be split between
> CMS and shared (i.e., that there is some code in concurrentGCThread.cpp
> specialized for CMS)?
> 
> 
> 
> Christian Wimmer wrote On 11/13/08 21:06,:
> 
> >...
> >2) duplicate files: the files "concurrentGCThread.cpp" and  
> >"concurrentGCThread.hpp" are present in two directories:  
> >"gc_implementation\concurrentMarkSweep" and "gc_implementation 
> >\shared". The content of the files is equal, so just deleting one 
> pair  
> >of files works.
> >
> >
> >  
> >
> 


From Jon.Masamitsu at Sun.COM  Fri Nov 14 10:27:04 2008
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 14 Nov 2008 10:27:04 -0800
Subject: HotSpot build problems on Windows
In-Reply-To: <f897de157a86.491d4289@sun.com>
References: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>
	<491DA8AA.4050303@sun.com> <f897de157a86.491d4289@sun.com>
Message-ID: <491DC2F8.1060900@sun.com>

Y Srinivas Ramakrishna wrote On 11/14/08 09:19,:

>Apologies! (mea culpa I am guessing.)
>
>Yes, the version(s) under concurrentMarkSweep should go away.
>I don't believe there's any CMS-specific
>code in there, so no need to split (at the moment at least).
>
>As Christian pointed out there's a .cpp as well as a .hpp that have
>to go. Then you may want to scan the includeDB's and shuffle include's
>around if/as needed.
>  
>

Is there something particular you had in mind with regard
to the includeDB's?  Those files don't include paths so
not sure what needs adjusting.

grep concurrentGCThread includeDB_*
includeDB_gc_concurrentMarkSweep:concurrentMarkSweepThread.hpp          
concurrentGCThread.hpp
includeDB_gc_g1:concurrentG1RefineThread.hpp           
concurrentGCThread.hpp
includeDB_gc_g1:concurrentMarkThread.hpp               
concurrentGCThread.hpp
includeDB_gc_g1:concurrentZFThread.hpp                 
concurrentGCThread.hpp
includeDB_gc_shared:concurrentGCThread.cpp                 
concurrentGCThread.hpp
includeDB_gc_shared:concurrentGCThread.cpp                  init.hpp
includeDB_gc_shared:concurrentGCThread.cpp                 
instanceRefKlass.hpp
includeDB_gc_shared:concurrentGCThread.cpp                 
interfaceSupport.hpp
includeDB_gc_shared:concurrentGCThread.cpp                  java.hpp
includeDB_gc_shared:concurrentGCThread.cpp                  javaCalls.hpp
includeDB_gc_shared:concurrentGCThread.cpp                  oop.inline.hpp
includeDB_gc_shared:concurrentGCThread.cpp                 
systemDictionary.hpp
includeDB_gc_shared:concurrentGCThread.hpp                  thread.hpp
includeDB_gc_shared:gcOverheadReporter.cpp                 
concurrentGCThread.hpp
includeDB_gc_parallel:safepoint.cpp                          
concurrentGCThread.hpp

>-- ramki
>
>----- Original Message -----
>From: Jon Masamitsu <Jon.Masamitsu at Sun.COM>
>Date: Friday, November 14, 2008 8:35 am
>Subject: Re: HotSpot build problems on Windows
>To: Christian Wimmer <wimmer at ssw.jku.at>
>Cc: hotspot-dev at openjdk.java.net
>
>
>  
>
>>As Christian has found we have in a repository
>>
>>./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
>>./share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>
>>The files are the same now.   I'm guessing that we
>>should delete
>>
>>./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
>>
>>I'll see if I can tell mercurial to do that.  Any concerns?  Were 
>>there any
>>thoughts that concurrentGCThread.cpp should be split between
>>CMS and shared (i.e., that there is some code in concurrentGCThread.cpp
>>specialized for CMS)?
>>
>>
>>
>>Christian Wimmer wrote On 11/13/08 21:06,:
>>
>>    
>>
>>>...
>>>2) duplicate files: the files "concurrentGCThread.cpp" and  
>>>"concurrentGCThread.hpp" are present in two directories:  
>>>"gc_implementation\concurrentMarkSweep" and "gc_implementation 
>>>\shared". The content of the files is equal, so just deleting one 
>>>      
>>>
>>pair  
>>    
>>
>>>of files works.
>>>
>>>
>>> 
>>>
>>>      
>>>



From Y.S.Ramakrishna at Sun.COM  Fri Nov 14 10:47:40 2008
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Fri, 14 Nov 2008 10:47:40 -0800
Subject: HotSpot build problems on Windows
In-Reply-To: <491DC2F8.1060900@sun.com>
References: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>
	<491DA8AA.4050303@sun.com> <f897de157a86.491d4289@sun.com>
	<491DC2F8.1060900@sun.com>
Message-ID: <fcccbe0279c7.491d574c@sun.com>



> >As Christian pointed out there's a .cpp as well as a .hpp that have
> >to go. Then you may want to scan the includeDB's and shuffle include's
> >around if/as needed.
> >  
> >
> 
> Is there something particular you had in mind with regard
> to the includeDB's?  Those files don't include paths so
> not sure what needs adjusting.

No, that looks good. I wanted us to make sure that redundant
concurrentGCThread.cpp's include's weren't left around in includeBD_concurrentMarkSweep. But that appears not to be the
case based on yr grep below. Thanks for checking!

-- ramki

> 
> grep concurrentGCThread includeDB_*
> includeDB_gc_concurrentMarkSweep:concurrentMarkSweepThread.hpp         
>  
> concurrentGCThread.hpp
> includeDB_gc_g1:concurrentG1RefineThread.hpp           
> concurrentGCThread.hpp
> includeDB_gc_g1:concurrentMarkThread.hpp               
> concurrentGCThread.hpp
> includeDB_gc_g1:concurrentZFThread.hpp                 
> concurrentGCThread.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                 
> concurrentGCThread.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                  init.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                 
> instanceRefKlass.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                 
> interfaceSupport.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                  java.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                  javaCalls.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                  oop.inline.hpp
> includeDB_gc_shared:concurrentGCThread.cpp                 
> systemDictionary.hpp
> includeDB_gc_shared:concurrentGCThread.hpp                  thread.hpp
> includeDB_gc_shared:gcOverheadReporter.cpp                 
> concurrentGCThread.hpp
> includeDB_gc_parallel:safepoint.cpp                          
> concurrentGCThread.hpp
> 
> >-- ramki
> >
> >----- Original Message -----
> >From: Jon Masamitsu <Jon.Masamitsu at Sun.COM>
> >Date: Friday, November 14, 2008 8:35 am
> >Subject: Re: HotSpot build problems on Windows
> >To: Christian Wimmer <wimmer at ssw.jku.at>
> >Cc: hotspot-dev at openjdk.java.net
> >
> >
> >  
> >
> >>As Christian has found we have in a repository
> >>
> >>./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
> >>./share/vm/gc_implementation/shared/concurrentGCThread.cpp
> >>
> >>The files are the same now.   I'm guessing that we
> >>should delete
> >>
> >>./share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
> >>
> >>I'll see if I can tell mercurial to do that.  Any concerns?  Were 
> >>there any
> >>thoughts that concurrentGCThread.cpp should be split between
> >>CMS and shared (i.e., that there is some code in concurrentGCThread.cpp
> >>specialized for CMS)?
> >>
> >>
> >>
> >>Christian Wimmer wrote On 11/13/08 21:06,:
> >>
> >>    
> >>
> >>>...
> >>>2) duplicate files: the files "concurrentGCThread.cpp" and  
> >>>"concurrentGCThread.hpp" are present in two directories:  
> >>>"gc_implementation\concurrentMarkSweep" and "gc_implementation 
> >>>\shared". The content of the files is equal, so just deleting one 
> >>>      
> >>>
> >>pair  
> >>    
> >>
> >>>of files works.
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> 


From Jon.Masamitsu at Sun.COM  Fri Nov 14 13:39:53 2008
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 14 Nov 2008 13:39:53 -0800
Subject: HotSpot build problems on Windows
In-Reply-To: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>
References: <BA9ED5E2-06AD-4DC0-B006-025B17E1EDC9@ssw.jku.at>
Message-ID: <491DF029.1000103@sun.com>

Christian,

I've added includeDB_gc_g1 as described in 3) below.
I've attached the file.  Could you verify that it works?

Thanks.

Jon


Christian Wimmer wrote On 11/13/08 21:06,:

>Hi
>
>When building the HotSpot VM on Windows using the create-script that  
>generates the Visual Studio project files, a bunch of problems occur.  
>I use Visual Studio 2008 on 64-bit Windows Vista, but most things are  
>independent of this configuration. Most problems seem to be related to  
>the recent integration of the G1 garbage collector.
>
>1) The most sever problem is that create.bat stops with the error  
>message "command line too long" when executing MakeDeps. The tool  
>takes so many parameters to configure the file structure for the VS  
>project. The integration of G1 added some new ones, so now the line is  
>too long. Even putting the source code directly into  C:\ so that  
>absolute paths are as short as possible does not help. My solution is  
>to abbreviate some command line flags, like "-additionalFile" and "- 
>additionalGeneratedFile". This works, but is no general solution for  
>the future.
>
>2) duplicate files: the files "concurrentGCThread.cpp" and  
>"concurrentGCThread.hpp" are present in two directories:  
>"gc_implementation\concurrentMarkSweep" and "gc_implementation 
>\shared". The content of the files is equal, so just deleting one pair  
>of files works.
>
>3) Missing includeDB reference for G1: In the file "make\windows 
>\projectfiles\common\Makefile", the reference of "includeDB_gc_g1" is  
>missing in the definition of "IncludeDBs_gc"
>
>4) The macro HOTSPOT_LIB_ARCH is not defined, i.e. the following line  
>is missing in the file "make\windows\makefiles\makedeps.make":
>	-define HOTSPOT_LIB_ARCH=\\\"$(BUILDARCH)\\\" \
>
>5) In the same file, the following define is necessary to avoid build  
>errors starting with Visual Studio 2005:
>	-define _CRT_SECURE_NO_WARNINGS \
>
>VS2008 also has a different project file format, however importing the  
>currently generated project files works fine so this is only a minor  
>issue.
>
>
>Christian
>  
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081114/00bf6ecd/attachment.ksh 

From erik.trimble at sun.com  Fri Nov 14 22:44:19 2008
From: erik.trimble at sun.com (erik.trimble at sun.com)
Date: Sat, 15 Nov 2008 06:44:19 +0000
Subject: hg: jdk7/hotspot/hotspot: 3 new changesets
Message-ID: <20081115064428.BA1F6D4C6@hg.openjdk.java.net>

Changeset: 42ca4002efc2
Author:    xdono
Date:      2008-11-06 12:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/42ca4002efc2

Added tag jdk7-b39 for changeset 49ca90d77f34

! .hgtags

Changeset: 7704802ec1ce
Author:    trims
Date:      2008-11-14 19:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7704802ec1ce

Merge


Changeset: 81a0cbe3b284
Author:    trims
Date:      2008-11-14 19:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/81a0cbe3b284

6771977: Bump HS14 build number to 07
Summary: Update the Hotspot build number to 07
Reviewed-by: jcoomes

! make/hotspot_version



From Paul.Hohensee at Sun.COM  Mon Nov 17 08:19:08 2008
From: Paul.Hohensee at Sun.COM (Paul Hohensee)
Date: Mon, 17 Nov 2008 11:19:08 -0500
Subject: [Fwd: JVM -instrumentanting the JDK classes]
In-Reply-To: <492196EC.2060509@Sun.COM>
References: <492196EC.2060509@Sun.COM>
Message-ID: <4921997C.4020305@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081117/5f52e7e3/attachment.html 

From wimmer at ssw.jku.at  Mon Nov 17 09:00:50 2008
From: wimmer at ssw.jku.at (Christian Wimmer)
Date: Mon, 17 Nov 2008 09:00:50 -0800
Subject: [Fwd: JVM -instrumentanting the JDK classes]
In-Reply-To: <4921997C.4020305@sun.com>
References: <492196EC.2060509@Sun.COM> <4921997C.4020305@sun.com>
Message-ID: <27321E73-172A-4A3D-8CF7-811DF8AAFE06@ssw.jku.at>

Hi

>> In order for our system to work, we need to change the code of the  
>> Java libraries - all of them. The changes imply adding a field  
>> (potentially two), and adding some code to the beginning and end of  
>> every method.
>>  Using Soot, I got to add the field and methods to the classes.  
>> However, there are exactly two classes (Object and String) that,  
>> when added a field, make the JVM crash on startup. I'm starting the  
>> Sun JVM with the parameter Xbootclasspath  pointing to the  
>> instrumented libraries.

The layout of some core classes is known by the HotSpot VM, for  
example the class String. The reason is that HotSpot must allocate  
String objects even from non-Java code, for example when a String  
constant is loaded from a class file's constant pool. Other classes  
are for example the weak references, which are specially handled in  
the garbage collector.
When you add fields to Object, you implicitly add to all other  
classes, so this also fails.

All known classes should be listed in the file src/share/vm/classfile/ 
javaClasses.hpp of the HotSpot source code, look for example at http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/42ca4002efc2/src/share/vm/classfile/javaClasses.hpp

Christian



From Keith.McGuigan at Sun.COM  Mon Nov 17 09:05:41 2008
From: Keith.McGuigan at Sun.COM (Keith McGuigan)
Date: Mon, 17 Nov 2008 12:05:41 -0500
Subject: [Fwd: JVM -instrumentanting the JDK classes]
In-Reply-To: <4921997C.4020305@sun.com>
References: <492196EC.2060509@Sun.COM> <4921997C.4020305@sun.com>
Message-ID: <4921A465.2070505@sun.com>


The JVM has some hardcoded expectations at to where to find fields in 
some of the critical classes.  I don't know that we have these 
assumptions listed anywhere (other than in the Hotspot source code: see 
JavaClasses::compute_hard_coded_offsets()).

If the addition of a field to a key class changes the location of a 
JVM-expected field, I would anticipate problems.  Because fields are 
(usually) grouped and put in runtime order by type, adding a new field 
at the end of a class in the source (or bytecode) probably won't 
guarantee is that it goes at the end at runtime and doesn't disturb the 
layout of known fields.

It looks like there is some logic in the class file parser (see the 
allocation_style code) that attempts to change allocation style for 
these classes, but I don't think it expects new fields.

--
- Keith

Paul Hohensee wrote:
> I've cc'ed hotspot-dev at openjdk.java.net, which is the place to ask.
> 
> Paul
> 
> Christine Flood wrote:
>>
>> I suppose he could use a tool like ASM to change the class 
>> dynamically, but I expect he will still get into trouble.
>>
>> Can anyone tell me definitively that this is a bad idea?
>>
>> I tried sending this to hs-chat, but apparently it is defunct.  Is 
>> there a better place to ask this question?
>>
>>
>> Christine
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> JVM -instrumentanting the JDK classes
>> From:
>> Mario Mendez-Lojo <marioml at ices.utexas.edu>
>> Date:
>> Mon, 17 Nov 2008 00:16:10 -0600
>> To:
>> Christine Flood <Christine.Flood at sun.com>
>>
>> To:
>> Christine Flood <Christine.Flood at sun.com>
>>
>>
>> Hi Christine,
>>
>> I'm Mario, one of Keshav's students at UT Austin. I have a question 
>> regarding some assumptions about the JVM & library classes.
>>
>> In order for our system to work, we need to change the code of the 
>> Java libraries - all of them. The changes imply adding a field 
>> (potentially two), and adding some code to the beginning and end of 
>> every method.
>>
>> Using Soot, I got to add the field and methods to the classes. 
>> However, there are exactly two classes (Object and String) that, when 
>> added a field, make the JVM crash on startup. I'm starting the Sun JVM 
>> with the parameter Xbootclasspath  pointing to the instrumented 
>> libraries.
>>
>> The question is: how safe our approach is? Even when the JVM is not 
>> crashing at startup, can I expect failures later on during runtime? 
>> Can you think about an alternative way of changing the behavior of the 
>> JDK classes in a less intrusive way?
>>
>> Thank you Christine!



From Paul.Hohensee at Sun.COM  Mon Nov 17 09:50:27 2008
From: Paul.Hohensee at Sun.COM (Paul Hohensee)
Date: Mon, 17 Nov 2008 12:50:27 -0500
Subject: [Fwd: JVM -instrumentanting the JDK classes]
In-Reply-To: <4921A465.2070505@sun.com>
References: <492196EC.2060509@Sun.COM> <4921997C.4020305@sun.com>
	<4921A465.2070505@sun.com>
Message-ID: <4921AEE3.1010303@sun.com>

It would be more work than what's proposed, but if it were me I'd
consider adding a field to the object header (in the vm: see oop.hpp)
and access it from Java via an intrinsic like array length(). Use some
weird accessor name that isn't likely to be used for anything else.

Paul

Keith McGuigan wrote:
>
> The JVM has some hardcoded expectations at to where to find fields in 
> some of the critical classes.  I don't know that we have these 
> assumptions listed anywhere (other than in the Hotspot source code: 
> see JavaClasses::compute_hard_coded_offsets()).
>
> If the addition of a field to a key class changes the location of a 
> JVM-expected field, I would anticipate problems.  Because fields are 
> (usually) grouped and put in runtime order by type, adding a new field 
> at the end of a class in the source (or bytecode) probably won't 
> guarantee is that it goes at the end at runtime and doesn't disturb 
> the layout of known fields.
>
> It looks like there is some logic in the class file parser (see the 
> allocation_style code) that attempts to change allocation style for 
> these classes, but I don't think it expects new fields.
>
> -- 
> - Keith
>
> Paul Hohensee wrote:
>> I've cc'ed hotspot-dev at openjdk.java.net, which is the place to ask.
>>
>> Paul
>>
>> Christine Flood wrote:
>>>
>>> I suppose he could use a tool like ASM to change the class 
>>> dynamically, but I expect he will still get into trouble.
>>>
>>> Can anyone tell me definitively that this is a bad idea?
>>>
>>> I tried sending this to hs-chat, but apparently it is defunct.  Is 
>>> there a better place to ask this question?
>>>
>>>
>>> Christine
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> Subject:
>>> JVM -instrumentanting the JDK classes
>>> From:
>>> Mario Mendez-Lojo <marioml at ices.utexas.edu>
>>> Date:
>>> Mon, 17 Nov 2008 00:16:10 -0600
>>> To:
>>> Christine Flood <Christine.Flood at sun.com>
>>>
>>> To:
>>> Christine Flood <Christine.Flood at sun.com>
>>>
>>>
>>> Hi Christine,
>>>
>>> I'm Mario, one of Keshav's students at UT Austin. I have a question 
>>> regarding some assumptions about the JVM & library classes.
>>>
>>> In order for our system to work, we need to change the code of the 
>>> Java libraries - all of them. The changes imply adding a field 
>>> (potentially two), and adding some code to the beginning and end of 
>>> every method.
>>>
>>> Using Soot, I got to add the field and methods to the classes. 
>>> However, there are exactly two classes (Object and String) that, 
>>> when added a field, make the JVM crash on startup. I'm starting the 
>>> Sun JVM with the parameter Xbootclasspath  pointing to the 
>>> instrumented libraries.
>>>
>>> The question is: how safe our approach is? Even when the JVM is not 
>>> crashing at startup, can I expect failures later on during runtime? 
>>> Can you think about an alternative way of changing the behavior of 
>>> the JDK classes in a less intrusive way?
>>>
>>> Thank you Christine!
>


From edilee at gmail.com  Mon Nov 17 10:49:21 2008
From: edilee at gmail.com (Edward Lee)
Date: Mon, 17 Nov 2008 12:49:21 -0600
Subject: C2 Scalar Replacement Behavior?
Message-ID: <dc07ed930811171049g279a732bj2c294c6d0d7fbf6@mail.gmail.com>

A couple questions about object scalar replacement in opto
(PhaseMacroExpand::eliminate_allocate_node):

1) Object allocations are eliminated only if they're only written to.
It seems that any field loads prevent it from being scalar replaced,
but I would have thought that after scalar replacement, a pair of
stores/loads would become plain plain def/use. Is there any particular
reason for this?

2) Allocations with multiple CheckCastPP nodes aren't eliminated. Is
it because it's known that allocations with non-unique CheckCastPP
definitely will have uses that make them non-eliminate-able? If not,
it seems that can_eliminate_allocation() would just need an extra
nested DU loop over each of the allocation's CheckCastPPs.

Just to make sure I'm understanding the code correctly, scalar
replacement behaves as..

1) Do escape analysis and mark allocations that NoEscape as possibly
scalar_replacable
2) For allocations with a single casts, make sure fields are only
stored to and the object is not returned/passed as arguments
2.1) Additionally keep track of safepoint uses for..
3) scalar_replacement() converts safepoint uses of the allocation into
SafePointScalarObjectNodes
4) Clean up uses of allocation by converting stores nodes into their
memory input and fix projections for control, memory, i/o

Ed


From Vladimir.Kozlov at Sun.COM  Mon Nov 17 12:35:17 2008
From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov)
Date: Mon, 17 Nov 2008 12:35:17 -0800
Subject: C2 Scalar Replacement Behavior?
In-Reply-To: <dc07ed930811171049g279a732bj2c294c6d0d7fbf6@mail.gmail.com>
References: <dc07ed930811171049g279a732bj2c294c6d0d7fbf6@mail.gmail.com>
Message-ID: <4921D585.4050700@sun.com>

Edward Lee wrote:
> A couple questions about object scalar replacement in opto
> (PhaseMacroExpand::eliminate_allocate_node):

Edward,

Please note, eliminate_allocate_node() is only the final
stage of the scalar replacement. Other parts of optimizer
also work for it.

> 
> 1) Object allocations are eliminated only if they're only written to.
> It seems that any field loads prevent it from being scalar replaced,
> but I would have thought that after scalar replacement, a pair of
> stores/loads would become plain plain def/use. Is there any particular
> reason for this?

All uses of scalar replaceable object's fields should be replaced
with values stored into the fields (or with default value 0 if
there were no stores). It happens during Global Value Numbering
optimizations (see LoadNode::split_through_phi() and
MemNode::optimize_memory_chain() in memnode.cpp).
We have to keep allocations if optimizer was not able to eliminate
all loads (for example, volatile fields).

> 
> 2) Allocations with multiple CheckCastPP nodes aren't eliminated. Is
> it because it's known that allocations with non-unique CheckCastPP
> definitely will have uses that make them non-eliminate-able? If not,

Only one unique CheckCastPP could be used to keep fields type aliasing
information during GVN optimizations.

> it seems that can_eliminate_allocation() would just need an extra
> nested DU loop over each of the allocation's CheckCastPPs.

The check in can_eliminate_allocation() is only a safeguard.
An object is marked as scalar_replaceable "optimistically"
if it has several CheckCastPP. It will be removed only if
optimizer will fold multiple CheckCastPP to one
and there are no any fields references.

> 
> Just to make sure I'm understanding the code correctly, scalar
> replacement behaves as..
> 
> 1) Do escape analysis and mark allocations that NoEscape as possibly
> scalar_replacable

Correct. And it also create new unique phis and type aliasing information
for all fields references of scalar_replaceable objects.

> 2) For allocations with a single casts, make sure fields are only
> stored to and the object is not returned/passed as arguments

Correct. Also an object will not be scalar replaced if values
of all fields are not found (value_from_mem() returns NULL).

> 2.1) Additionally keep track of safepoint uses for..
> 3) scalar_replacement() converts safepoint uses of the allocation into
> SafePointScalarObjectNodes

Correct. It is used to created a data used for an object reconstruction
during deoptimization.

> 4) Clean up uses of allocation by converting stores nodes into their
> memory input and fix projections for control, memory, i/o

Correct.

> 
> Ed

Thanks,
Vladimir


From David.Holmes at Sun.COM  Tue Nov 18 22:11:20 2008
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Wed, 19 Nov 2008 16:11:20 +1000
Subject: Common build definitions/targets for Solaris & Linux ?
Message-ID: <4923AE08.1040008@sun.com>

Is there any reason why the main definitions and targets in 
make/solaris/Makefile and make/linux/Makefile (see below) can't be 
factored out into a common file?

(The OS version check would of course need to be specialized.)

David
------------

# There is a (semi-) regular correspondence between make targets and 
actions:
#
#       Target          Tree Type       Build Dir
#
#       debug           compiler2       <os>_<arch>_compiler2/debug
#       fastdebug       compiler2       <os>_<arch>_compiler2/fastdebug
#       jvmg            compiler2       <os>_<arch>_compiler2/jvmg
#       optimized       compiler2       <os>_<arch>_compiler2/optimized
#       profiled        compiler2       <os>_<arch>_compiler2/profiled
#       product         compiler2       <os>_<arch>_compiler2/product
#
#       debug1          compiler1       <os>_<arch>_compiler1/debug
#       fastdebug1      compiler1       <os>_<arch>_compiler1/fastdebug
#       jvmg1           compiler1       <os>_<arch>_compiler1/jvmg
#       optimized1      compiler1       <os>_<arch>_compiler1/optimized
#       profiled1       compiler1       <os>_<arch>_compiler1/profiled
#       product1        compiler1       <os>_<arch>_compiler1/product
#
#       debugcore       core            <os>_<arch>_core/debug
#       fastdebugcore   core            <os>_<arch>_core/fastdebug
#       jvmgcore        core            <os>_<arch>_core/jvmg
#       optimizedcore   core            <os>_<arch>_core/optimized
#       profiledcore    core            <os>_<arch>_core/profiled
#       productcore     core            <os>_<arch>_core/product
#
# What you get with each target:
#
# debug*     - "thin" libjvm_g - debug info linked into the gamma_g launcher
# fastdebug* - optimized compile, but with asserts enabled
# jvmg*      - "fat" libjvm_g - debug info linked into libjvm_g.so
# optimized* - optimized compile, no asserts
# profiled*  - gprof
# product*   - the shippable thing:  optimized compile, no asserts, 
-DPRODUCT

# This target list needs to be coordinated with the usage message
# in the build.sh script:
TARGETS           = debug jvmg fastdebug optimized profiled product

SUBDIR_DOCS       = $(OSNAME)_$(BUILDARCH)_docs
SUBDIRS_C1        = $(addprefix 
$(OSNAME)_$(BUILDARCH)_compiler1/,$(TARGETS))
SUBDIRS_C2        = $(addprefix 
$(OSNAME)_$(BUILDARCH)_compiler2/,$(TARGETS))
SUBDIRS_TIERED    = $(addprefix $(OSNAME)_$(BUILDARCH)_tiered/,$(TARGETS))
SUBDIRS_CORE      = $(addprefix $(OSNAME)_$(BUILDARCH)_core/,$(TARGETS))
SUBDIRS_KERNEL    = $(addprefix $(OSNAME)_$(BUILDARCH)_kernel/,$(TARGETS))

TARGETS_C2        = $(TARGETS)
TARGETS_C1        = $(addsuffix 1,$(TARGETS))
TARGETS_TIERED    = $(addsuffix tiered,$(TARGETS))
TARGETS_CORE      = $(addsuffix core,$(TARGETS))
TARGETS_KERNEL    = $(addsuffix kernel,$(TARGETS))

BUILDTREE_MAKE    = $(GAMMADIR)/make/$(OSNAME)/makefiles/buildtree.make
BUILDTREE_VARS    = GAMMADIR=$(GAMMADIR) OS_FAMILY=$(OSNAME) 
ARCH=$(SRCARCH) BUILDARCH=$(BUILDARCH) LIBARCH=$(LIBARCH)
BUILDTREE_VARS   += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION) 
HOTSPOT_BUILD_VERSION=$(HOTSPOT_BUILD_VERSION) 
JRE_RELEASE_VERSION=$(JRE_RELEASE_VERSION)

BUILDTREE         = $(MAKE) -f $(BUILDTREE_MAKE) $(BUILDTREE_VARS)

#-------------------------------------------------------------------------------

# Could make everything by default, but that would take a while.
all:
         @echo "Try '$(MAKE) <target> ...'  where <target> is one or 
more of"
         @echo "  $(TARGETS_C2)"
         @echo "  $(TARGETS_C1)"
         @echo "  $(TARGETS_CORE)"

checks: check_os_version check_j2se_version

# We do not want people accidentally building on old systems (e.g. Linux 
2.2.x,
# Solaris 2.5.1, 2.6).
# Disable this check by setting DISABLE_HOTSPOT_OS_VERSION_CHECK=ok.

SUPPORTED_OS_VERSION = 5.7 5.8 5.9 5.10 5.11
OS_VERSION := $(shell uname -r)
EMPTY_IF_NOT_SUPPORTED = $(filter $(SUPPORTED_OS_VERSION),$(OS_VERSION))

check_os_version:
ifeq ($(DISABLE_HOTSPOT_OS_VERSION_CHECK)$(EMPTY_IF_NOT_SUPPORTED),)
         $(QUIETLY) >&2 echo "*** This OS is not supported:" `uname -a`; 
exit 1;
endif

# jvmti.make requires XSLT (J2SE 1.4.x or newer):
XSLT_CHECK      = $(RUN.JAVAP) javax.xml.transform.TransformerFactory
# If not found then fail fast.
check_j2se_version:
         $(QUIETLY) $(XSLT_CHECK) > /dev/null 2>&1; \
         if [ $$? -ne 0 ]; then \
           $(RUN.JAVA) -version; \
           echo "*** An XSLT processor (J2SE 1.4.x or newer) is required" \
           "to bootstrap this build" 1>&2; \
           exit 1; \
         fi

$(SUBDIRS_TIERED): $(BUILDTREE_MAKE)
         $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks
         $(BUILDTREE) VARIANT=tiered

$(SUBDIRS_C2): $(BUILDTREE_MAKE)
ifdef FORCE_TIERED
         $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks
                 $(BUILDTREE) VARIANT=tiered FORCE_TIERED=1
else
         $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks
                 $(BUILDTREE) VARIANT=compiler2
endif

$(SUBDIRS_C1): $(BUILDTREE_MAKE)
         $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks
         $(BUILDTREE) VARIANT=compiler1

$(SUBDIRS_CORE): $(BUILDTREE_MAKE)
         $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks
         $(BUILDTREE) VARIANT=core

$(SUBDIRS_KERNEL): $(BUILDTREE_MAKE)
         $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks
         $(BUILDTREE) VARIANT=kernel

# Define INSTALL=y at command line to automatically copy JVM into JAVA_HOME

$(TARGETS_C2):  $(SUBDIRS_C2)
         cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && $(MAKE) $(MFLAGS)
         cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && ./test_gamma
ifdef INSTALL
         cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && $(MAKE) $(MFLAGS) install
endif

$(TARGETS_TIERED):  $(SUBDIRS_TIERED)
         cd $(OSNAME)_$(BUILDARCH)_tiered/$(patsubst %tiered,%,$@) && 
$(MAKE) $(MFLAGS)
         cd $(OSNAME)_$(BUILDARCH)_tiered/$(patsubst %tiered,%,$@) && 
./test_gamma
ifdef INSTALL
         cd $(OSNAME)_$(BUILDARCH)_tiered/$(patsubst %tiered,%,$@) && 
$(MAKE) $(MFLAGS) install
endif

$(TARGETS_C1):  $(SUBDIRS_C1)
         cd $(OSNAME)_$(BUILDARCH)_compiler1/$(patsubst %1,%,$@) && 
$(MAKE) $(MFLAGS)
         cd $(OSNAME)_$(BUILDARCH)_compiler1/$(patsubst %1,%,$@) && 
./test_gamma
ifdef INSTALL
         cd $(OSNAME)_$(BUILDARCH)_compiler1/$(patsubst %1,%,$@) && 
$(MAKE) $(MFLAGS) install
endif

$(TARGETS_CORE):  $(SUBDIRS_CORE)
         cd $(OSNAME)_$(BUILDARCH)_core/$(patsubst %core,%,$@) && 
$(MAKE) $(MFLAGS)
         cd $(OSNAME)_$(BUILDARCH)_core/$(patsubst %core,%,$@) && 
./test_gamma
ifdef INSTALL
         cd $(OSNAME)_$(BUILDARCH)_core/$(patsubst %core,%,$@) && 
$(MAKE) $(MFLAGS) install
endif

$(TARGETS_KERNEL):  $(SUBDIRS_KERNEL)
         cd $(OSNAME)_$(BUILDARCH)_kernel/$(patsubst %kernel,%,$@) && 
$(MAKE) $(MFLAGS)
         cd $(OSNAME)_$(BUILDARCH)_kernel/$(patsubst %kernel,%,$@) && 
./test_gamma
ifdef INSTALL
         cd $(OSNAME)_$(BUILDARCH)_kernel/$(patsubst %kernel,%,$@) && 
$(MAKE) $(MFLAGS) install
endif

# Just build the tree, and nothing else:
tree:      $(SUBDIRS_C2)
tree1:     $(SUBDIRS_C1)
treecore:  $(SUBDIRS_CORE)
treekernel:  $(SUBDIRS_KERNEL)

# Doc target.  This is the same for all build options.
#     Hence create a docs directory beside ...$(ARCH)_[...]
docs: checks
         $(QUIETLY) mkdir -p $(SUBDIR_DOCS)
         $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/makefiles/jvmti.make 
$(MFLAGS) $(BUILDTREE_VARS) JvmtiOutDir=$(SUBDIR_DOCS) jvmtidocs

# Synonyms for win32-like targets.
compiler2:  jvmg product

compiler1:  jvmg1 product1

core: jvmgcore productcore

clean_docs:
         rm -rf $(SUBDIR_DOCS)

clean_compiler1 clean_compiler2 clean_core clean_kernel:
         rm -rf $(OSNAME)_$(BUILDARCH)_$(subst clean_,,$@)

clean:  clean_compiler2 clean_compiler1 clean_core clean_docs clean_kernel

include $(GAMMADIR)/make/$(OSNAME)/makefiles/cscope.make

#-------------------------------------------------------------------------------

.PHONY: $(TARGETS_C2) $(TARGETS_C1) $(TARGETS_CORE)
.PHONY: tree tree1 treecore
.PHONY: all compiler1 compiler2 core
.PHONY: clean clean_compiler1 clean_compiler2 clean_core docs clean_docs
.PHONY: checks check_os_version check_j2se_version





From volker.simonis at gmail.com  Wed Nov 19 02:08:55 2008
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Nov 2008 11:08:55 +0100
Subject: How to test a fresh HotSpot build on Windows without building the
	whole JDK?
Message-ID: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>

Hi,

I've just built a 64-bit debug HotSpot on Windows and I realized that
under Windows there's no "gamma" launcher like under Linux/Solaris
which can be used to run a freshly build HotSpot with an existing JDK
by setting the JAVA_HOME environment variable. The quick hack of just
replacing the "jvm.dll" (together with "jvm.map" and "jvm.pdb") of a
recent 64-bit Java 7 debug release (b39) with my newly build versions
of these files didn't work either:

Error: loading: d:\Software\jdk1.7.0_x64_b39\jre\bin\server\jvm.dll

Is there a simple way how one can run a freshly build  HotSpot on
Windows without building the whole JDK?

I should also mention that I built the HotSpot with VS 2005 which to
my knowledge is different from the version that was used to build the
Java 7 binaries. May this be a problem?

Any suggestions are highly welcome.

Volker


From Thomas.Rodriguez at Sun.COM  Wed Nov 19 07:10:14 2008
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Wed, 19 Nov 2008 07:10:14 -0800
Subject: How to test a fresh HotSpot build on Windows without building the
	whole JDK?
In-Reply-To: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>
References: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>
Message-ID: <21B996DB-4682-443F-8B85-36EDB9FB9525@sun.com>

That's a reasonable way to test your built jvm.dll so I would suspect  
some build problem.  Did you build it using the generated project file  
inside VS or make/windows/build.bat?  It's possible there are some  
issues with the generated project file.  The machinery for generating  
that is separate from our normal make process so it will sometimes be  
broken until some one notices it.  You might compare the symbol  
exports between your build and the standard one.

tom

On Nov 19, 2008, at 2:08 AM, Volker Simonis wrote:

> Hi,
>
> I've just built a 64-bit debug HotSpot on Windows and I realized that
> under Windows there's no "gamma" launcher like under Linux/Solaris
> which can be used to run a freshly build HotSpot with an existing JDK
> by setting the JAVA_HOME environment variable. The quick hack of just
> replacing the "jvm.dll" (together with "jvm.map" and "jvm.pdb") of a
> recent 64-bit Java 7 debug release (b39) with my newly build versions
> of these files didn't work either:
>
> Error: loading: d:\Software\jdk1.7.0_x64_b39\jre\bin\server\jvm.dll
>
> Is there a simple way how one can run a freshly build  HotSpot on
> Windows without building the whole JDK?
>
> I should also mention that I built the HotSpot with VS 2005 which to
> my knowledge is different from the version that was used to build the
> Java 7 binaries. May this be a problem?
>
> Any suggestions are highly welcome.
>
> Volker



From volker.simonis at gmail.com  Wed Nov 19 10:49:20 2008
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Nov 2008 19:49:20 +0100
Subject: How to test a fresh HotSpot build on Windows without building the
	whole JDK?
In-Reply-To: <21B996DB-4682-443F-8B85-36EDB9FB9525@sun.com>
References: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>
	<21B996DB-4682-443F-8B85-36EDB9FB9525@sun.com>
Message-ID: <d65861880811191049l7653beb5x58552edaa01844cf@mail.gmail.com>

Here are my findings so far:

I build on the command line of course (hey, I'm a real man:) From
hotspot/make from within a Cygwin bash I do:

ALT_BOOTDIR=/cygdrive/d/Software/jdk1.6.0_10
ALT_OUTPUTDIR=../../build/hotspot_amd64_fastdebug
ALT_JDK_IMPORT_PATH=/cygdrive/d/Software/jdk1.7.0_x64_debug_b39 make
fastdebug 2>&1 | tee ../../build/hotspot_amd64_fastdebug.log

Besides some warnings which I had to eliminate and the additional
'cl'-paramters "/D _CRT_SECURE_NO_DEPRECATE /D
_CRT_NONSTDC_NO_DEPRECATE" which I had to supply (I'll submit a patch,
once I'm done), the build succeeded. Just for the sake of completness,
the Makefile calls "nmake" with the following command line, which
looks quite reasonable to me:

nmake /NOLOGO -f d:/priv/d046063/OpenJDK/jdk7/hotspot/make/windows/build.make \
                      Variant=compiler2 \
                      WorkSpace=d:\\priv\\d046063\\OpenJDK\\jdk7\\hotspot \
                      BootStrapDir=d:\\Software\\jdk1.6.0_10 \
                      BuildUser=D046063 \
                       LP64=1 ARCH=x86 BUILDARCH=amd64
Platform_arch=x86 Platform_arch_model=x86_64 JDK_MKTG_VERSION=7.0
JDK_MAJOR_VER=1 JDK_MINOR_VER=7 JDK_MICRO_VER=0
JAVA_HOME=d:\\Software\\jdk1.6.0_10
OUTPUTDIR=d:\\priv\\d046063\\OpenJDK\\jdk7\\build\\hotspot_amd64_fastdebug
GAMMADIR=d:\\priv\\d046063\\OpenJDK\\jdk7\\hotspot MAKE_VERBOSE=y
HOTSPOT_RELEASE_VERSION=14.0-b06 JRE_RELEASE_VERSION="1.7.0"
HOTSPOT_BUILD_VERSION=internal fastdebug

After the build I've copied the "jvm.dll" into the server directory of
a JDK 7 debug build (b39) and got the error described in my previous
mail. Menawhile I found out (by using "DependencyWalker" on the
generated "jvm.dll") that "jvm.dll" is dynamically linked to
"msvcr80.dll" which can not be found when java is started. So I copied
"msvcr80.dll" into the same directory where "java.exe" is located. Now
the dll is found, but I get another error:

C Run-Time Error R6034 - "An application has made an attempt to load
the C runtime library incorrectly."

The Microsoft documentation at
http://msdn.microsoft.com/en-us/library/ms235560(VS.80).aspx explains:
"An application has made an attempt to load the C runtime library
without using a manifest. This is an unsupported way to load Visual
C++ DLLs. You need to modify your application to build with a
manifest. For more information, see the "Visual C++ Libraries as
Shared Side-by-Side Assemblies" topic in the product documentation."

This also explains why "msvcr80.dll" couldn't be found in the first
place - it is located in the SideBySide Assemblies directory under:
C:\WINDOWS\WinSxS\

So apparently I have to link jvm.dll somhow specially if I use VS2005
and use "mt.exe" in order to add a mainfest to it. Does anybody has
experience with this?

Thank you and best regards,
Volker

PS: I just rememered the change "6764892: VS2008 changes required to
compile hotspot sources" which has been recently posted on the list:
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c07cda72b7d.
But it was in hotspot-comp and I synced jdk7:(  I'll try it tomorrow -
looks like this could solve my problems...


On 11/19/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> That's a reasonable way to test your built jvm.dll so I would suspect some build problem.  Did you build it using the generated project file inside VS or make/windows/build.bat?  It's possible there are some issues with the generated project file.  The machinery for generating that is separate from our normal make process so it will sometimes be broken until some one notices it.  You might compare the symbol exports between your build and the standard one.
>
>  tom
>
>
>  On Nov 19, 2008, at 2:08 AM, Volker Simonis wrote:
>
>
> >  Hi,
> >
> >  I've just built a 64-bit debug HotSpot on Windows and I realized that
> >  under Windows there's no "gamma" launcher like under Linux/Solaris
> >  which can be used to run a freshly build HotSpot with an existing JDK
> >  by setting the JAVA_HOME environment variable. The quick hack of just
> >  replacing the "jvm.dll" (together with "jvm.map" and "jvm.pdb") of a
> >  recent 64-bit Java 7 debug release (b39) with my newly build versions
> >  of these files didn't work either:
> >
> >  Error: loading: d:\Software\jdk1.7.0_x64_b39\jre\bin\server\jvm.dll
> >
> >  Is there a simple way how one can run a freshly build  HotSpot on
> >  Windows without building the whole JDK?
> >
> >  I should also mention that I built the HotSpot with VS 2005 which to
> >  my knowledge is different from the version that was used to build the
> >  Java 7 binaries. May this be a problem?
> >
> >  Any suggestions are highly welcome.
> >
> >  Volker
> >
>
>


From Tim.Bell at Sun.COM  Wed Nov 19 11:43:50 2008
From: Tim.Bell at Sun.COM (Tim Bell)
Date: Wed, 19 Nov 2008 11:43:50 -0800
Subject: How to test a fresh HotSpot build on Windows without building the
	whole JDK?
In-Reply-To: <d65861880811191049l7653beb5x58552edaa01844cf@mail.gmail.com>
References: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>
	<21B996DB-4682-443F-8B85-36EDB9FB9525@sun.com>
	<d65861880811191049l7653beb5x58552edaa01844cf@mail.gmail.com>
Message-ID: <49246C76.606@sun.com>

Volker Simonis wrote:
> Here are my findings so far:
[... snip! ...]

> So apparently I have to link jvm.dll somhow specially if I use VS2005
> and use "mt.exe" in order to add a mainfest to it. Does anybody has
> experience with this?

The VS2005 and VS2008 runtime libraries (msvcr80.dll or msvcr90.dll respectively) will refuse 
to run if they do not find the correct 'manifest' information when loaded.

Starting with VS2005, every use of the ld command to create a .dll or a .exe will also create a 
.manifest file in the same directory.  That manifest is what the runtime library is checking.

If you move or copy a .exe or a .dll, your choices are:

1) Also put the .manifest file there so the runtime can find it.

2) Use the mt command to insert the manifest as an attribute on the .dll or .exe file just 
created (the 'ld' command itself will not do that).  Once you add the manifest as an attribute, 
you don't need to keep track of the extra .manifest file.

The changes in 6764892 [Note 1] implement option 2.  This is what all the work under 6523947 
will do.

> Thank you and best regards,
> Volker
> 
> PS: I just rememered the change "6764892: VS2008 changes required to
> compile hotspot sources" which has been recently posted on the list:
> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c07cda72b7d.
> But it was in hotspot-comp and I synced jdk7:(  I'll try it tomorrow -
> looks like this could solve my problems...

You want these changes.  They are headed for the JDK7 HotSpot master, but have not been pushed 
up yet.  I just marked 6764892 as public, so it should be pushed in the bug parade in the next 
few days.  The relevant information is in the changeset referenced in [Note 1].

Since you are building your JVM using VS2005, you will get msvcr80.dll with it.  Inserting that 
jvm.dll into a pre-built JDK 7 will be problematic because the current JDK 7 builds use Visual 
Studio 2003 and hence msvcr71.dll with all other native libraries.  In our experience, nothing 
good will happen if you try mixing two runtimes in the same process address space.  As a result 
of this incompatibility, I have been doing full control builds of the entire JDK while working 
on the fixes for 6523947 and related bug-IDs 6728735, 6733976, 6764892, 6759959, 6754862 [Note 2].

If you can build the gamma launcher using VS2005 and run that to quickly test your JVM you will 
probably be better off.

Hope this helps -

Tim Bell

[Note 1]
   http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c07cda72b7d

[Note 2]
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6523947
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728735
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6733976
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6764892
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6759959
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6754862



From vladimir.kozlov at sun.com  Wed Nov 19 13:09:36 2008
From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com)
Date: Wed, 19 Nov 2008 21:09:36 +0000
Subject: hg: jdk7/hotspot/hotspot: 11 new changesets
Message-ID: <20081119210957.07A20D6CC@hg.openjdk.java.net>

Changeset: 3c07cda72b7d
Author:    tbell
Date:      2008-11-11 22:01 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3c07cda72b7d

6764892: VS2008 changes required to compile hotspot sources
Summary: Minor changes required to build using the Visual Studio 2008 compiler
Reviewed-by: kvn, ohair

! make/windows/makefiles/adlc.make
! make/windows/makefiles/compile.make
! make/windows/makefiles/debug.make
! make/windows/makefiles/defs.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/product.make
! make/windows/makefiles/sa.make
! src/cpu/x86/vm/register_definitions_x86.cpp

Changeset: 334969144810
Author:    never
Date:      2008-11-11 23:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/334969144810

6758445: loop heads that are exception entry points can crash during count_edges/mark_loops
Reviewed-by: kvn, jrose

! src/share/vm/c1/c1_IR.cpp

Changeset: 364141474b40
Author:    never
Date:      2008-11-12 05:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/364141474b40

Merge


Changeset: 4d20a3aaf1ab
Author:    kvn
Date:      2008-11-12 11:01 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4d20a3aaf1ab

6769748: Fix solaris makefiles for the case when "CC -V" produces several lines
Summary: Fix solaris makefiles for 5.10 compilers
Reviewed-by: jcoomes

! make/solaris/makefiles/debug.make
! make/solaris/makefiles/fastdebug.make
! make/solaris/makefiles/i486.make
! make/solaris/makefiles/jvmg.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/product.make
! make/solaris/makefiles/sparc.make
! make/solaris/makefiles/sparcWorks.make
! make/solaris/makefiles/sparcv9.make
! make/solaris/makefiles/vm.make

Changeset: a45484ea312d
Author:    jrose
Date:      2008-11-12 22:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a45484ea312d

6653858: dynamic languages need to be able to load anonymous classes
Summary: low-level privileged sun.misc.Unsafe.defineAnonymousClass
Reviewed-by: kvn

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/includeDB_gc_parallel
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/utilities/constantTag.hpp

Changeset: 275a3b7ff0d6
Author:    jrose
Date:      2008-11-12 23:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/275a3b7ff0d6

6770949: minor tweaks before 6655638
Summary: minor cleanups & tuning of array.hpp, debug.cpp, growableArray.hpp, hashtable.cpp
Reviewed-by: kvn

! src/share/vm/utilities/array.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/growableArray.hpp
! src/share/vm/utilities/hashtable.cpp

Changeset: c1345e85f901
Author:    kvn
Date:      2008-11-13 14:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c1345e85f901

6767659: Conversion from i486 to x86 missed some entries in makefiles
Summary: Fixed missed entries.
Reviewed-by: never

! make/linux/makefiles/top.make
! make/solaris/makefiles/amd64.make
! make/solaris/makefiles/dtrace.make
! make/solaris/makefiles/fastdebug.make
! make/solaris/makefiles/i486.make
! make/solaris/makefiles/sparc.make
! make/solaris/makefiles/top.make
! src/share/vm/adlc/archDesc.cpp

Changeset: de78b80cedec
Author:    kvn
Date:      2008-11-18 12:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/de78b80cedec

6772413: code cleanup
Summary: Removed lines in adm64.make with interpret.o and moved few constant strings from header files.
Reviewed-by: never

! make/solaris/makefiles/amd64.make
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/perfMemory.hpp

Changeset: b1d6a3e95810
Author:    kvn
Date:      2008-11-18 12:40 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b1d6a3e95810

6766316: assert(!nocreate,"Cannot build a phi for a block already parsed.")
Summary: Don't use the invariant local information if there are irreducible loops.
Reviewed-by: never

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

Changeset: 87559db65269
Author:    kvn
Date:      2008-11-18 14:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/87559db65269

6773078: UseCompressedOops: assert(kid == 0L || s->_leaf->in(0) == 0L,"internal operands have no control")
Summary: Don't set the control edge of a klass load node.
Reviewed-by: never

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

Changeset: 491a904952f2
Author:    kvn
Date:      2008-11-19 09:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/491a904952f2

Merge




From volker.simonis at gmail.com  Wed Nov 19 13:20:59 2008
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Nov 2008 22:20:59 +0100
Subject: How to test a fresh HotSpot build on Windows without building the
	whole JDK?
In-Reply-To: <49246C76.606@sun.com>
References: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>
	<21B996DB-4682-443F-8B85-36EDB9FB9525@sun.com>
	<d65861880811191049l7653beb5x58552edaa01844cf@mail.gmail.com>
	<49246C76.606@sun.com>
Message-ID: <d65861880811191320kb45910je90459e78e3a8115@mail.gmail.com>

Hi Tim,

thank you very much for the hints and insights. I'll try the manifest
stuff tomorrow. Regarding your suggestion to use the gamma launcher, -
I'd like to, this was my initial intention - however there's no gamma
launcher for windows (i.e. 'hotspot/src/os/windows/' contains no
'launcher/' subdirectory with the relavant files like the
corresponding 'linux/' and 'solaris/' subdirectories). Did you mean I
should build something equivalent to the Unix gamma launcher for
Windows by using the corresponding files from the jdk workspace?
Would this be worthwhile if you say that it is not very good to mix
different runtimes in the same address space? Aren't the other native
libraries of the binary JDK  7 build dependant on "msvcr71.dll" as
well?

Thank you and best regards,
Volker

PS: I also had to set "/D _CRT_NONSTDC_NO_DEPRECATE" (see
http://msdn.microsoft.com/en-us/library/ms235384(VS.80).aspx) to make
some deprecated functions visible without a leading "_". Morover I had
to insert some cast to avoid warnigs like "result of 32-bit operation
converted to 64-bit...). Didn't you had these problems when you did
your VS 2008 build? I couldn't find any related changes but if you
want, I can post the diffs.


On 11/19/08, Tim Bell <Tim.Bell at sun.com> wrote:
> Volker Simonis wrote:
>
> > Here are my findings so far:
> >
>  [... snip! ...]
>
>
> > So apparently I have to link jvm.dll somhow specially if I use VS2005
> > and use "mt.exe" in order to add a mainfest to it. Does anybody has
> > experience with this?
> >
>
>  The VS2005 and VS2008 runtime libraries (msvcr80.dll or msvcr90.dll
> respectively) will refuse to run if they do not find the correct 'manifest'
> information when loaded.
>
>  Starting with VS2005, every use of the ld command to create a .dll or a
> .exe will also create a .manifest file in the same directory.  That manifest
> is what the runtime library is checking.
>
>  If you move or copy a .exe or a .dll, your choices are:
>
>  1) Also put the .manifest file there so the runtime can find it.
>
>  2) Use the mt command to insert the manifest as an attribute on the .dll or
> .exe file just created (the 'ld' command itself will not do that).  Once you
> add the manifest as an attribute, you don't need to keep track of the extra
> .manifest file.
>
>  The changes in 6764892 [Note 1] implement option 2.  This is what all the
> work under 6523947 will do.
>
>
> > Thank you and best regards,
> > Volker
> >
> > PS: I just rememered the change "6764892: VS2008 changes required to
> > compile hotspot sources" which has been recently posted on the list:
> >
> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c07cda72b7d.
> > But it was in hotspot-comp and I synced jdk7:(  I'll try it tomorrow -
> > looks like this could solve my problems...
> >
>
>  You want these changes.  They are headed for the JDK7 HotSpot master, but
> have not been pushed up yet.  I just marked 6764892 as public, so it should
> be pushed in the bug parade in the next few days.  The relevant information
> is in the changeset referenced in [Note 1].
>
>  Since you are building your JVM using VS2005, you will get msvcr80.dll with
> it.  Inserting that jvm.dll into a pre-built JDK 7 will be problematic
> because the current JDK 7 builds use Visual Studio 2003 and hence
> msvcr71.dll with all other native libraries.  In our experience, nothing
> good will happen if you try mixing two runtimes in the same process address
> space.  As a result of this incompatibility, I have been doing full control
> builds of the entire JDK while working on the fixes for 6523947 and related
> bug-IDs 6728735, 6733976, 6764892, 6759959, 6754862 [Note 2].
>
>  If you can build the gamma launcher using VS2005 and run that to quickly
> test your JVM you will probably be better off.
>
>  Hope this helps -
>
>  Tim Bell
>
>  [Note 1]
>
> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c07cda72b7d
>
>  [Note 2]
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6523947
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728735
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6733976
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6764892
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6759959
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6754862
>
>


From Tim.Bell at Sun.COM  Wed Nov 19 19:24:17 2008
From: Tim.Bell at Sun.COM (Tim Bell)
Date: Wed, 19 Nov 2008 19:24:17 -0800
Subject: How to test a fresh HotSpot build on Windows without building the
	whole JDK?
In-Reply-To: <d65861880811191320kb45910je90459e78e3a8115@mail.gmail.com>
References: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>
	<21B996DB-4682-443F-8B85-36EDB9FB9525@sun.com>
	<d65861880811191049l7653beb5x58552edaa01844cf@mail.gmail.com>
	<49246C76.606@sun.com>
	<d65861880811191320kb45910je90459e78e3a8115@mail.gmail.com>
Message-ID: <4924D861.3050205@sun.com>

Volker Simonis wrote:

> thank you very much for the hints and insights. I'll try the manifest
> stuff tomorrow. Regarding your suggestion to use the gamma launcher, -
> I'd like to, this was my initial intention - however there's no gamma
> launcher for windows (i.e. 'hotspot/src/os/windows/' contains no
> 'launcher/' subdirectory with the relavant files like the
> corresponding 'linux/' and 'solaris/' subdirectories). Did you mean I
> should build something equivalent to the Unix gamma launcher for
> Windows by using the corresponding files from the jdk workspace?

I didn't realize the gamma launcher was missing on Windows, but it
sure looks that way when I check into it.  Sorry for the bad advice
there on my part.

> Would this be worthwhile if you say that it is not very good to mix
> different runtimes in the same address space?

Mixing runtimes will probably fail right away.  If not it will lead to
bizarre failures or odd behavior later.

> Aren't the other native libraries of the binary JDK  7 build dependant on "msvcr71.dll" as
> well?

Yes, they are.

> Thank you and best regards,
> Volker
> 
> PS: I also had to set "/D _CRT_NONSTDC_NO_DEPRECATE" (see
> http://msdn.microsoft.com/en-us/library/ms235384(VS.80).aspx) to make
> some deprecated functions visible without a leading "_".

I have been ignoring these warnings.  I agree there are a lot of them.

The longer term plan is to fix warnings, but that comes after we get a
build that works, and it will be done under other bug-IDs.

> to insert some cast to avoid warnigs like "result of 32-bit operation
> converted to 64-bit...). Didn't you had these problems when you did
> your VS 2008 build? I couldn't find any related changes but if you
> want, I can post the diffs.

I am fixing the missing casts and other minor code changes required to
build with the new VS compiler, with help from developers in other
product areas such as AWT, HotSpot, deploy.

Tim


From igor.veresov at sun.com  Wed Nov 19 19:29:24 2008
From: igor.veresov at sun.com (igor.veresov at sun.com)
Date: Thu, 20 Nov 2008 03:29:24 +0000
Subject: hg: jdk7/hotspot/hotspot: 6 new changesets
Message-ID: <20081120032936.48BF5D7D0@hg.openjdk.java.net>

Changeset: 122d10c82f3f
Author:    jcoomes
Date:      2008-10-29 06:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/122d10c82f3f

6765804: GC "dead ratios" should be unsigned
Reviewed-by: ysr, tonyp

! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp
! src/share/vm/memory/space.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/memory/tenuredGeneration.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 03f4fdd1b6af
Author:    jcoomes
Date:      2008-11-11 22:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/03f4fdd1b6af

6718879: cannot build on solaris nevada
Reviewed-by: xlu

! src/os/solaris/vm/os_solaris.cpp

Changeset: 96c6da8f095c
Author:    jcoomes
Date:      2008-11-07 12:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/96c6da8f095c

6769128: failure to run generateJvmOffsets is ignored
Reviewed-by: xlu

! make/solaris/makefiles/dtrace.make

Changeset: da9cb4e97a5f
Author:    iveresov
Date:      2008-11-14 14:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/da9cb4e97a5f

6770608: G1: Mutator thread can flush barrier and satb queues during safepoint
6660573: G1: BigApps Failure : guarantee(satb_mq_set.completed_buffers_num() == 0,"invariant")
Summary: When exiting a mutator thread is removed from the thread list before it has a chance to flush its SATB and barrier queues. If GC happens at this moment the objects that are refererred from these queues can be moved, which will case a crash. The fix is simply to flush the buffers before removing a thread from the list.
Reviewed-by: jcoomes, tonyp

! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/gc_implementation/g1/ptrQueue.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: 8fa025608ec6
Author:    jmasa
Date:      2008-11-18 14:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8fa025608ec6

6771742: Remove duplicate files from G1 merge
Summary: Remove duplicate files and add includeDB_gc_g1 file in windows Makefile
Reviewed-by: jcoomes, ysr

! make/windows/projectfiles/common/Makefile
- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp

Changeset: b5e603f2e024
Author:    iveresov
Date:      2008-11-19 14:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b5e603f2e024

Merge

! make/solaris/makefiles/dtrace.make
- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp
! src/share/vm/runtime/globals.hpp



From twisti at complang.tuwien.ac.at  Thu Nov 20 00:23:27 2008
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Thu, 20 Nov 2008 09:23:27 +0100
Subject: hotspot/make/solaris/makefiles/sparcWorks.make misses 64-bit
	flags with Sun Studio 5.10
In-Reply-To: <49196796.1080605@sun.com>
References: <1226352851.989.10.camel@localhost.localdomain>
	<4918AC14.2040400@Sun.COM> <4918B0C2.40504@sun.com>
	<1226355121.989.14.camel@localhost.localdomain>
	<49196796.1080605@sun.com>
Message-ID: <1227169407.8404.7.camel@localhost.localdomain>

On Tue, 2008-11-11 at 03:08 -0800, Erik Trimble wrote:
> >> I would suggest to use 5.9 for your work if you have
> >> access to it.
> >>     
> >
> > Yeah, it's a pity OpenSolaris updates everything without asking.  I'll
> > try if I can downgrade.

I forgot to tell you that the downgrade worked and I'm now building with
5.9 again.

> Not to be quite as pessimistic as Vladimir, I expect that we will update 
> to the 5.10 compilers shortly after Sun Studio 13 GAs.   That is, likely 
> 2-3 months afterwards.
> 
> Now, I can't do anything other than guess when SS13 will be out.  
> Sometime in the first half of 2009, maybe?

It's not that important, I just tried it because it is the new default
in Indiana.

- Christian



From volker.simonis at gmail.com  Thu Nov 20 02:43:06 2008
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 20 Nov 2008 11:43:06 +0100
Subject: How to test a fresh HotSpot build on Windows without building the
	whole JDK?
In-Reply-To: <4924D861.3050205@sun.com>
References: <d65861880811190208s41d048b0m2b0797521060a53e@mail.gmail.com>
	<21B996DB-4682-443F-8B85-36EDB9FB9525@sun.com>
	<d65861880811191049l7653beb5x58552edaa01844cf@mail.gmail.com>
	<49246C76.606@sun.com>
	<d65861880811191320kb45910je90459e78e3a8115@mail.gmail.com>
	<4924D861.3050205@sun.com>
Message-ID: <d65861880811200243p4c05daaan161e65cfb509b891@mail.gmail.com>

I've just applied the "mt" trick, copied the the new "jvm.dll" into a
binary JDK 7 release and the GOOD NEWS is: it seems to work!!! I don't
pretend that this will work under all circumstances, but I've run some
HelloWorld programs and played around with the SwingSet2-Demo and
observed no problems or crashes until now. So this may be an option
for small HotSpot tests...

Building the whole OpenJDK with a different compiler to avoid the the
"mixed runtimes" problems will be hard anyway, because one still needs
the binary plugins which still contain a native .dll as far as I've
just checked.

On 11/20/08, Tim Bell <Tim.Bell at sun.com> wrote:
> Volker Simonis wrote:
>
>
> > thank you very much for the hints and insights. I'll try the manifest
> > stuff tomorrow. Regarding your suggestion to use the gamma launcher, -
> > I'd like to, this was my initial intention - however there's no gamma
> > launcher for windows (i.e. 'hotspot/src/os/windows/' contains no
> > 'launcher/' subdirectory with the relavant files like the
> > corresponding 'linux/' and 'solaris/' subdirectories). Did you mean I
> > should build something equivalent to the Unix gamma launcher for
> > Windows by using the corresponding files from the jdk workspace?
> >
>
>  I didn't realize the gamma launcher was missing on Windows, but it
>  sure looks that way when I check into it.  Sorry for the bad advice
>  there on my part.
>
>
> > Would this be worthwhile if you say that it is not very good to mix
> > different runtimes in the same address space?
> >
>
>  Mixing runtimes will probably fail right away.  If not it will lead to
>  bizarre failures or odd behavior later.
>
>
> > Aren't the other native libraries of the binary JDK  7 build dependant on
> "msvcr71.dll" as
> > well?
> >
>
>  Yes, they are.
>
>
> > Thank you and best regards,
> > Volker
> >
> > PS: I also had to set "/D _CRT_NONSTDC_NO_DEPRECATE" (see
> >
> http://msdn.microsoft.com/en-us/library/ms235384(VS.80).aspx)
> to make
> > some deprecated functions visible without a leading "_".
> >
>
>  I have been ignoring these warnings.  I agree there are a lot of them.
>
>  The longer term plan is to fix warnings, but that comes after we get a
>  build that works, and it will be done under other bug-IDs.
>
>
> > to insert some cast to avoid warnigs like "result of 32-bit operation
> > converted to 64-bit...). Didn't you had these problems when you did
> > your VS 2008 build? I couldn't find any related changes but if you
> > want, I can post the diffs.
> >
>
>  I am fixing the missing casts and other minor code changes required to
>  build with the new VS compiler, with help from developers in other
>  product areas such as AWT, HotSpot, deploy.
>
>  Tim
>


From marioml at ices.utexas.edu  Thu Nov 20 12:27:05 2008
From: marioml at ices.utexas.edu (Mario Mendez-Lojo)
Date: Thu, 20 Nov 2008 14:27:05 -0600
Subject: Check the validity of a .class file
Message-ID: <4925C819.1030803@ices.utexas.edu>

Hi guys,

I'm manipulating bytecode using the Soot tool. However, sometimes I'll output 
bytecode that is incorrect (Soot is not able to detect this): local variables 
declared as of void type, for instance. The transformed, invalid class will make 
the JVM crash.

The question is: is there any tool that can check whether a .class file is in 
the right format?

Thanks!


From Keith.McGuigan at Sun.COM  Thu Nov 20 13:41:05 2008
From: Keith.McGuigan at Sun.COM (Keith McGuigan)
Date: Thu, 20 Nov 2008 16:41:05 -0500
Subject: Check the validity of a .class file
In-Reply-To: <4925C819.1030803@ices.utexas.edu>
References: <4925C819.1030803@ices.utexas.edu>
Message-ID: <4925D971.7020206@sun.com>

Mario Mendez-Lojo wrote:
> Hi guys,
> 
> I'm manipulating bytecode using the Soot tool. However, sometimes I'll 
> output bytecode that is incorrect (Soot is not able to detect this): 
> local variables declared as of void type, for instance. The transformed, 
> invalid class will make the JVM crash.
> 
> The question is: is there any tool that can check whether a .class file 
> is in the right format?

Are you running without the JVM's verifier turned on?  With the 
verifier, the VM should kick out with a VerifyError or ClassFormatError 
if there's any problem with the classfile format or bytecode.  It should 
be on by default, but you can run with 'java -verify' just to be sure.

If the JVM crashes when you feed it a bad classfile, please send the 
classfile to me for diagnosis.  This should not happen and would likely 
be a bug in the JVM.

--
- Keith


From Thomas.Rodriguez at Sun.COM  Thu Nov 20 13:46:17 2008
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 20 Nov 2008 13:46:17 -0800
Subject: Check the validity of a .class file
In-Reply-To: <4925C819.1030803@ices.utexas.edu>
References: <4925C819.1030803@ices.utexas.edu>
Message-ID: <5F645F47-5FA3-4FB6-9DDB-1396E82DA8B3@sun.com>

I believe the ASM framework has a verifier as part of it's toolchain.   
I don't know how good it is in terms complaining about exactly the  
same things the JVM would but at a minimum it seems like it would be  
able to sanity check the bytecodes.

tom

On Nov 20, 2008, at 12:27 PM, Mario Mendez-Lojo wrote:

> Hi guys,
>
> I'm manipulating bytecode using the Soot tool. However, sometimes  
> I'll output bytecode that is incorrect (Soot is not able to detect  
> this): local variables declared as of void type, for instance. The  
> transformed, invalid class will make the JVM crash.
>
> The question is: is there any tool that can check whether a .class  
> file is in the right format?
>
> Thanks!



From marioml at ices.utexas.edu  Thu Nov 20 13:48:20 2008
From: marioml at ices.utexas.edu (Mario Mendez-Lojo)
Date: Thu, 20 Nov 2008 15:48:20 -0600
Subject: Check the validity of a .class file
In-Reply-To: <4925D971.7020206@sun.com>
References: <4925C819.1030803@ices.utexas.edu> <4925D971.7020206@sun.com>
Message-ID: <4925DB24.4020701@ices.utexas.edu>

You are right about the -verify option in the JVM. However, I'm asking about a 
tool to *statically* check the validity of a .class file, possibly in the 
context of the Hotspot JVM. In this way, I don't need to run the program in 
order to  figure out if the instrumented bytecode is valid.

It seems to me that verifying the correctness of the bytecode can be done at 
compile time, but maybe I'm wrong about this and we can only do the verification 
at runtime, within the VM.

Keith McGuigan wrote:
> Mario Mendez-Lojo wrote:
>> Hi guys,
>>
>> I'm manipulating bytecode using the Soot tool. However, sometimes I'll 
>> output bytecode that is incorrect (Soot is not able to detect this): 
>> local variables declared as of void type, for instance. The 
>> transformed, invalid class will make the JVM crash.
>>
>> The question is: is there any tool that can check whether a .class 
>> file is in the right format?
> 
> Are you running without the JVM's verifier turned on?  With the 
> verifier, the VM should kick out with a VerifyError or ClassFormatError 
> if there's any problem with the classfile format or bytecode.  It should 
> be on by default, but you can run with 'java -verify' just to be sure.
> 
> If the JVM crashes when you feed it a bad classfile, please send the 
> classfile to me for diagnosis.  This should not happen and would likely 
> be a bug in the JVM.
> 
> -- 
> - Keith


From Keith.McGuigan at Sun.COM  Thu Nov 20 14:14:51 2008
From: Keith.McGuigan at Sun.COM (Keith McGuigan)
Date: Thu, 20 Nov 2008 17:14:51 -0500
Subject: Check the validity of a .class file
In-Reply-To: <4925DB24.4020701@ices.utexas.edu>
References: <4925C819.1030803@ices.utexas.edu> <4925D971.7020206@sun.com>
	<4925DB24.4020701@ices.utexas.edu>
Message-ID: <4925E15B.9050909@sun.com>

Mario Mendez-Lojo wrote:
> You are right about the -verify option in the JVM. However, I'm asking 
> about a tool to *statically* check the validity of a .class file, 
> possibly in the context of the Hotspot JVM. In this way, I don't need to 
> run the program in order to  figure out if the instrumented bytecode is 
> valid.

Well, verification in the JVM occurs as part of the loading, so the 
bytecode actually is statically examined.  It doesn't have to run, the 
verifier is kicked off at link time, not run time.  This means you 
should be able to check a class by simply calling Class.forName() in a 
java program (ANY java program, not necessarily the one you're 
instrumenting for), and if you get an exception then the bytecode is 
malformed.

> It seems to me that verifying the correctness of the bytecode can be 
> done at compile time, but maybe I'm wrong about this and we can only do 
> the verification at runtime, within the VM.

So long as you have definitions for any referenced classes, you should 
be able to perform the correctness check outside the JVM with no 
problem.  Of course you might have to implement it yourself :)  Just 
check the JVM spec for the specific rules concerning the format and type 
checks that need to be performed.   These checks could be done at any 
time by preprocessing tools, there's no VM-magic there, really.

IMO, leveraging the built-in verifier in the JVM would be the way to go, 
if you can.  Just spawn a side process that does the Class.forName() 
trick (or any other way of getting the class loaded and linked) and 
check for VerifyErrors there.

--
- Keith


From twisti at complang.tuwien.ac.at  Fri Nov 21 00:18:15 2008
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Fri, 21 Nov 2008 09:18:15 +0100
Subject: Check the validity of a .class file
In-Reply-To: <4925E15B.9050909@sun.com>
References: <4925C819.1030803@ices.utexas.edu> <4925D971.7020206@sun.com>
	<4925DB24.4020701@ices.utexas.edu>  <4925E15B.9050909@sun.com>
Message-ID: <1227255495.11551.3.camel@localhost.localdomain>

On Thu, 2008-11-20 at 17:14 -0500, Keith McGuigan wrote:
> Well, verification in the JVM occurs as part of the loading, so the 
> bytecode actually is statically examined.  It doesn't have to run, the 
> verifier is kicked off at link time, not run time.  This means you 

Really?  HotSpot verifies all methods during link time not during
compile time (well, first interpreter invocation)?

- Christian



From Keith.McGuigan at Sun.COM  Fri Nov 21 05:52:55 2008
From: Keith.McGuigan at Sun.COM (Keith McGuigan)
Date: Fri, 21 Nov 2008 08:52:55 -0500
Subject: Check the validity of a .class file
In-Reply-To: <1227255495.11551.3.camel@localhost.localdomain>
References: <4925C819.1030803@ices.utexas.edu> <4925D971.7020206@sun.com>
	<4925DB24.4020701@ices.utexas.edu> <4925E15B.9050909@sun.com>
	<1227255495.11551.3.camel@localhost.localdomain>
Message-ID: <4926BD37.2080207@sun.com>

Christian Thalinger wrote:
> On Thu, 2008-11-20 at 17:14 -0500, Keith McGuigan wrote:
>> Well, verification in the JVM occurs as part of the loading, so the 
>> bytecode actually is statically examined.  It doesn't have to run, the 
>> verifier is kicked off at link time, not run time.  This means you 
> 
> Really?  HotSpot verifies all methods during link time not during
> compile time (well, first interpreter invocation)?

Yeah, pretty much.

Hotspot (and all other spec-compliant JVMs) verify the entire class at 
link time, which is usually the point just before when the static 
initializers execute.   Check sections like 2.17.3 in the JVM spec to 
get the exact details of when this happens and what causes it.

All methods of a class are checked, even those that might not be 
executed for a while (as per the spec).  So a verification error in any 
method will prevent any methods in that class from running.

Most class format errors not related to the bytecode will be picked up 
at classfile parse time, of course, which occurs when the class is loaded.

--
- Keith


From twisti at complang.tuwien.ac.at  Fri Nov 21 06:36:37 2008
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Fri, 21 Nov 2008 15:36:37 +0100
Subject: Check the validity of a .class file
In-Reply-To: <4926BD37.2080207@sun.com>
References: <4925C819.1030803@ices.utexas.edu> <4925D971.7020206@sun.com>
	<4925DB24.4020701@ices.utexas.edu> <4925E15B.9050909@sun.com>
	<1227255495.11551.3.camel@localhost.localdomain>
	<4926BD37.2080207@sun.com>
Message-ID: <1227278197.11551.8.camel@localhost.localdomain>

On Fri, 2008-11-21 at 08:52 -0500, Keith McGuigan wrote:
> Christian Thalinger wrote:
> > On Thu, 2008-11-20 at 17:14 -0500, Keith McGuigan wrote:
> >> Well, verification in the JVM occurs as part of the loading, so the 
> >> bytecode actually is statically examined.  It doesn't have to run, the 
> >> verifier is kicked off at link time, not run time.  This means you 
> > 
> > Really?  HotSpot verifies all methods during link time not during
> > compile time (well, first interpreter invocation)?
> 
> Yeah, pretty much.
> 
> Hotspot (and all other spec-compliant JVMs) verify the entire class at 
> link time, which is usually the point just before when the static 
> initializers execute.   Check sections like 2.17.3 in the JVM spec to 
> get the exact details of when this happens and what causes it.

"The Java programming language allows an implementation flexibility as
to when linking activities (and, because of recursion, loading) take
place, provided that the semantics of the language are respected, that a
class or interface is completely verified and prepared before it is
initialized, ..."

Uhm... reading that section again makes me think CACAO has a problem in
this area.  We verify methods while compiling, not while linking the
class file.  I should write a small testcase to see if CACAO does not
behave like the RI.

- Christian



From john.coomes at sun.com  Mon Nov 24 14:23:54 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Mon, 24 Nov 2008 22:23:54 +0000
Subject: hg: jdk7/hotspot: Added tag jdk7-b40 for changeset 44be42de6693
Message-ID: <20081124222355.30A94DB03@hg.openjdk.java.net>

Changeset: 8c34e4abcb43
Author:    xdono
Date:      2008-11-20 11:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/rev/8c34e4abcb43

Added tag jdk7-b40 for changeset 44be42de6693

! .hgtags



From john.coomes at sun.com  Mon Nov 24 14:27:15 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Mon, 24 Nov 2008 22:27:15 +0000
Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b40 for changeset 184e21992f47
Message-ID: <20081124222717.1C223DB08@hg.openjdk.java.net>

Changeset: c90eeda9594e
Author:    xdono
Date:      2008-11-20 11:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/c90eeda9594e

Added tag jdk7-b40 for changeset 184e21992f47

! .hgtags



From john.coomes at sun.com  Mon Nov 24 14:33:31 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Mon, 24 Nov 2008 22:33:31 +0000
Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b40 for changeset 54946f466e2c
Message-ID: <20081124223334.0E291DB13@hg.openjdk.java.net>

Changeset: 0758bd3e2852
Author:    xdono
Date:      2008-11-20 11:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/0758bd3e2852

Added tag jdk7-b40 for changeset 54946f466e2c

! .hgtags



From john.coomes at sun.com  Mon Nov 24 14:37:06 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Mon, 24 Nov 2008 22:37:06 +0000
Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b40 for changeset 70a6ac6dd737
Message-ID: <20081124223708.636B9DB1B@hg.openjdk.java.net>

Changeset: a8379d24aa03
Author:    xdono
Date:      2008-11-20 11:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/a8379d24aa03

Added tag jdk7-b40 for changeset 70a6ac6dd737

! .hgtags



From john.coomes at sun.com  Mon Nov 24 14:40:51 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Mon, 24 Nov 2008 22:40:51 +0000
Subject: hg: jdk7/hotspot/jdk: 12 new changesets
Message-ID: <20081124224329.A5E03DB20@hg.openjdk.java.net>

Changeset: 64da1f751c0f
Author:    martin
Date:      2008-10-24 20:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/64da1f751c0f

6761678: (ann) SecurityException in AnnotationInvocationHandler.getMemberMethods
Summary: Move call to getDeclaredMethods inside doPrivileged
Reviewed-by: darcy, mullan
Contributed-by: jjb at google.com

! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
+ test/java/lang/annotation/ParameterAnnotations.java

Changeset: 1a324821b463
Author:    tbell
Date:      2008-10-24 20:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1a324821b463

Merge


Changeset: 76ecb928e83a
Author:    emcmanus
Date:      2008-10-27 14:02 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/76ecb928e83a

6763639: Remove "rawtypes" warnings from JMX code
Reviewed-by: dfuchs

! make/netbeans/jmx/build.xml
! src/share/classes/com/sun/jmx/event/LeaseManager.java
! src/share/classes/com/sun/jmx/event/LeaseRenewer.java
! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java
! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java
! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java
! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java
! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java
! src/share/classes/com/sun/jmx/mbeanserver/SecureClassLoaderRepository.java
! src/share/classes/com/sun/jmx/mbeanserver/Util.java
! src/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java
! src/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java
! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java
! src/share/classes/com/sun/jmx/remote/internal/ProxyInputStream.java
! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
! src/share/classes/com/sun/jmx/remote/internal/Unmarshal.java
! src/share/classes/com/sun/jmx/remote/security/FileLoginModule.java
! src/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java
! src/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java
! src/share/classes/com/sun/jmx/remote/util/ClassLoaderWithRepository.java
! src/share/classes/com/sun/jmx/remote/util/ClassLogger.java
! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java
! src/share/classes/com/sun/jmx/remote/util/EventClientConnection.java
! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java
! src/share/classes/javax/management/AttributeList.java
! src/share/classes/javax/management/DefaultLoaderRepository.java
! src/share/classes/javax/management/JMRuntimeException.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanServerFactory.java
! src/share/classes/javax/management/MBeanServerInvocationHandler.java
! src/share/classes/javax/management/StandardMBean.java
! src/share/classes/javax/management/event/EventClientDelegate.java
! src/share/classes/javax/management/event/EventSubscriber.java
! src/share/classes/javax/management/loading/DefaultLoaderRepository.java
! src/share/classes/javax/management/loading/MLet.java
! src/share/classes/javax/management/loading/MLetObjectInputStream.java
! src/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java
! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java
! src/share/classes/javax/management/openmbean/ArrayType.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/management/openmbean/CompositeType.java
! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenType.java
! src/share/classes/javax/management/openmbean/SimpleType.java
! src/share/classes/javax/management/openmbean/TabularDataSupport.java
! src/share/classes/javax/management/openmbean/TabularType.java
! src/share/classes/javax/management/relation/MBeanServerNotificationFilter.java
! src/share/classes/javax/management/relation/RelationService.java
! src/share/classes/javax/management/relation/RelationSupport.java
! src/share/classes/javax/management/relation/Role.java
! src/share/classes/javax/management/relation/RoleList.java
! src/share/classes/javax/management/relation/RoleResult.java
! src/share/classes/javax/management/relation/RoleUnresolved.java
! src/share/classes/javax/management/relation/RoleUnresolvedList.java
! src/share/classes/javax/management/remote/JMXConnectorFactory.java
! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java
! src/share/classes/javax/management/remote/rmi/RMIConnection.java
! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
! src/share/classes/javax/management/remote/rmi/RMIConnector.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java
! src/share/classes/javax/management/timer/Timer.java

Changeset: 98ac3d398ed6
Author:    chegar
Date:      2008-10-28 16:14 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/98ac3d398ed6

6756771: com.sun.net.httpserver.HttpServer should handle POSTs larger than 2Gig
Summary: update implementation to use long instead of int
Reviewed-by: michaelm

! src/share/classes/sun/net/httpserver/ExchangeImpl.java
! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java
! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/httpserver/ServerImpl.java
+ test/com/sun/net/httpserver/bugs/FixedLengthInputStream.java

Changeset: 58e52eb46bd3
Author:    emcmanus
Date:      2008-10-28 18:21 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/58e52eb46bd3

6763051: MXBean: Incorrect type names for parametrized dealing with arrays (openType)
6713777: developer diagnosability of errors in uncompliant mxbean interfaces
Reviewed-by: dfuchs

! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java
! src/share/classes/javax/management/MBeanServerInvocationHandler.java
+ test/javax/management/mxbean/ExceptionDiagnosisTest.java
! test/javax/management/mxbean/TypeNameTest.java

Changeset: 8dcde0b16199
Author:    emcmanus
Date:      2008-10-30 17:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8dcde0b16199

6252609: Two different default descriptor forms defined for ModelMBeanInfoSupport
6253137: Documentation for NotificationListener's handback parameter is confusing
6368691: javadoc for JMX Descriptors has bugs and is very hard to navigate.
6602699: support for async notification of mbeaninfo update
6759612: [javadoc] EventClient.NOTIFS_LOST has a garbled href to addEventClientListener
6759619: Clarify what EventClient.getEventClientNotificationInfo does
6759622: Clarify what EventClient.getListeners list does
Summary: Documentation fixes, plus simple bugfix for 6759619.
Reviewed-by: dfuchs

! src/share/classes/javax/management/Descriptor.java
! src/share/classes/javax/management/MBeanInfo.java
! src/share/classes/javax/management/MBeanServer.java
! src/share/classes/javax/management/NotificationListener.java
! src/share/classes/javax/management/event/EventClient.java
! src/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java
! test/javax/management/eventService/CustomForwarderTest.java
! test/javax/management/mxbean/TypeNameTest.java

Changeset: cdfb6f963a60
Author:    emcmanus
Date:      2008-10-30 18:19 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cdfb6f963a60

6450848: make it easier to get the ObjectName of a JMX Proxy
Summary: Rework proxy javadoc to explain how to do this.
Reviewed-by: sjiang

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

Changeset: 4ff842aee1fd
Author:    mullan
Date:      2008-10-30 17:24 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4ff842aee1fd

6764553: com.sun.org.apache.xml.internal.security.utils.IdResolver is not thread safe
Reviewed-by: valeriep

! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java

Changeset: f246770bcc78
Author:    mullan
Date:      2008-10-30 17:28 -0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f246770bcc78

Merge


Changeset: 8d17cc67a857
Author:    emcmanus
Date:      2008-10-31 17:34 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8d17cc67a857

6766173: Spec should say that createMBean wraps a constructor RuntimeException in a RuntimeMBeanException
Summary: JMX spec clarification
Reviewed-by: dfuchs

! src/share/classes/javax/management/MBeanServerConnection.java
! src/share/classes/javax/management/namespace/MBeanServerSupport.java
! test/javax/management/MBeanServer/MBeanExceptionTest.java

Changeset: 2201dad60231
Author:    tbell
Date:      2008-11-07 11:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2201dad60231

Merge


Changeset: d00c685ae55e
Author:    xdono
Date:      2008-11-20 11:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d00c685ae55e

Added tag jdk7-b40 for changeset 2201dad60231

! .hgtags



From john.coomes at sun.com  Mon Nov 24 14:49:43 2008
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Mon, 24 Nov 2008 22:49:43 +0000
Subject: hg: jdk7/hotspot/langtools: 14 new changesets
Message-ID: <20081124225007.00C8DDB25@hg.openjdk.java.net>

Changeset: 6508d7e812e1
Author:    mcimadamore
Date:      2008-10-23 17:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6508d7e812e1

6732484: Bound error on wildcard code
Summary: Check.checkExtends should cope with captured type-variables
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/wildcards/T6732484.java

Changeset: 4d2d8b6459e1
Author:    mcimadamore
Date:      2008-10-23 17:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4d2d8b6459e1

6711619: javac doesn't allow access to protected members in intersection types
Summary: Accordingly to new accessibility rules all members of intersection types (but private ones) should be accessible
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/generics/6531090/T6531090b.java
+ test/tools/javac/generics/6711619/T6711619a.java
+ test/tools/javac/generics/6711619/T6711619a.out
+ test/tools/javac/generics/6711619/T6711619b.java
+ test/tools/javac/generics/6711619/T6711619b.out

Changeset: db77bf6adb53
Author:    mcimadamore
Date:      2008-10-23 18:00 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/db77bf6adb53

6487370: javac incorrectly gives ambiguity warning with override-equivalent abstract inherited methods
Summary: Javac should not compare erased return types when checking for ambiguity errors during overload resolution
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/generics/6487370/T6487370.java

Changeset: 433ee48257c0
Author:    mcimadamore
Date:      2008-10-23 18:10 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/433ee48257c0

6548436: Incorrect inconvertible types error
Summary: Types.rewrite quantifiers should cope with captured type-variables properly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6548436/T6548436a.java
+ test/tools/javac/cast/6548436/T6548436b.java
+ test/tools/javac/cast/6548436/T6548436c.java
+ test/tools/javac/cast/6548436/T6548436d.java

Changeset: c6e3fc6dda61
Author:    mcimadamore
Date:      2008-10-23 18:29 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c6e3fc6dda61

6557954: Inner class type parameters doesn't get substituted when checking type well-formedness
Summary: Validator.visitTypeApply should substitute all formal typevars with actual parameters
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/T6557954.java

Changeset: 5e54a59bcee7
Author:    mcimadamore
Date:      2008-10-24 12:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5e54a59bcee7

6680106: StackOverFlowError for Cyclic inheritance in TypeParameters with ArrayType Bounds
Summary: Javac ends up in an infinite loop while attributing mutually referring array type-parameter bounds
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/generics/typevars/6680106/T6680106.java
+ test/tools/javac/generics/typevars/6680106/T6680106.out

Changeset: a23e1dc02698
Author:    mcimadamore
Date:      2008-10-24 12:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a23e1dc02698

6746184: javac fails to compile call to public varargs method
Summary: javac's resolution process should go through all steps described in JLS 15.12.2.2
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/varargs/T6746184.java

Changeset: ddd75a295501
Author:    mcimadamore
Date:      2008-10-24 12:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ddd75a295501

6758789: Some method resolution diagnostic should be improved
Summary: Recent work on diagnostics left out some resolution corner cases
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/api/Formattable.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/6758789/T6758789a.java
+ test/tools/javac/6758789/T6758789a.out
+ test/tools/javac/6758789/T6758789b.java
+ test/tools/javac/6758789/T6758789b.out
! test/tools/javac/generics/inference/6718364/T6718364.out

Changeset: 638d45788c9e
Author:    mcimadamore
Date:      2008-10-24 12:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/638d45788c9e

6762569: Javac crashes with AssertionError in Types.containedBy
Summary: Types.containedBy should be more liberal with UndetVars
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
- test/tools/javac/generics/wildcards/6651719/T6651719b.java
+ test/tools/javac/generics/wildcards/6762569/T6762569a.java
+ test/tools/javac/generics/wildcards/6762569/T6762569b.java

Changeset: 8d7fa40da0eb
Author:    tbell
Date:      2008-10-24 20:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8d7fa40da0eb

Merge

- test/tools/javac/generics/wildcards/6651719/T6651719b.java

Changeset: 5ebe90e0afff
Author:    jjg
Date:      2008-10-27 14:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5ebe90e0afff

6764226: ListTest fails on javap output with bad characters
Reviewed-by: darcy

! test/tools/javap/ListTest.java

Changeset: 4f7b344a1ce0
Author:    mcimadamore
Date:      2008-10-28 14:05 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4f7b344a1ce0

6763518: Impossible to suppress raw-type warnings
Summary: Check.validate(Type) should be invoked after -Xlint is augmented in Attr.visitVarDef
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/6304921/T6304921.out
+ test/tools/javac/warnings/T6763518.java

Changeset: 32e309883246
Author:    tbell
Date:      2008-11-07 11:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/32e309883246

Merge


Changeset: 82463d00ac70
Author:    xdono
Date:      2008-11-20 11:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/82463d00ac70

Added tag jdk7-b40 for changeset 32e309883246

! .hgtags



From erik.trimble at sun.com  Tue Nov 25 11:06:37 2008
From: erik.trimble at sun.com (erik.trimble at sun.com)
Date: Tue, 25 Nov 2008 19:06:37 +0000
Subject: hg: jdk7/hotspot/hotspot: 3 new changesets
Message-ID: <20081125190643.8C7B1DC1A@hg.openjdk.java.net>

Changeset: 316c0b576ea1
Author:    xdono
Date:      2008-11-20 11:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/316c0b576ea1

Added tag jdk7-b40 for changeset 81a0cbe3b284

! .hgtags

Changeset: ab42bab113e0
Author:    trims
Date:      2008-11-21 16:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ab42bab113e0

Merge

- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp

Changeset: f9d938ede196
Author:    trims
Date:      2008-11-21 16:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f9d938ede196

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

! make/hotspot_version



From keith.mcguigan at sun.com  Wed Nov 26 09:20:03 2008
From: keith.mcguigan at sun.com (keith.mcguigan at sun.com)
Date: Wed, 26 Nov 2008 17:20:03 +0000
Subject: hg: jdk7/hotspot/hotspot: 5 new changesets
Message-ID: <20081126172015.D847DDC9A@hg.openjdk.java.net>

Changeset: 2b42b31e7928
Author:    coleenp
Date:      2008-11-21 08:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2b42b31e7928

6676175: BigApps crash JVM Client VM (build 10.0-b22, mixed mode, sharing) with SIGSEGV (0xb)
Summary: Add test for biased locking epoch before walking own thread stack in case of rare race
Reviewed-by: phh, never

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

Changeset: ba7f9d894282
Author:    kamg
Date:      2008-11-21 15:10 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ba7f9d894282

Merge

- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp

Changeset: 171e581e8161
Author:    xlu
Date:      2008-11-22 00:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/171e581e8161

6554406: Change switch UseVMInterruptibleIO default to false (sol)
Summary: The default value of UseVMInterruptibleIO is changed to false for JDK 7, but the default isn't changed for JDK 6 and earlier.
Reviewed-by: never, acorn, dholmes, kamg, alanb

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

Changeset: b22701a8b88f
Author:    coleenp
Date:      2008-11-24 14:45 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b22701a8b88f

6474243: suspicious jvmti code that uses oop unsafely across GC point
Summary: oop stored in unsafely in Lscratch noticed by visual inspection will not be updated by GC.
Reviewed-by: kamg, never, kvn

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

Changeset: a60eabc24e2c
Author:    kamg
Date:      2008-11-25 15:59 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a60eabc24e2c

Merge




From igor.veresov at sun.com  Wed Nov 26 12:17:23 2008
From: igor.veresov at sun.com (igor.veresov at sun.com)
Date: Wed, 26 Nov 2008 20:17:23 +0000
Subject: hg: jdk7/hotspot/hotspot: 4 new changesets
Message-ID: <20081126201732.345B5DCB5@hg.openjdk.java.net>

Changeset: 00b023ae2d78
Author:    ysr
Date:      2008-11-20 12:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/00b023ae2d78

6722113: CMS: Incorrect overflow handling during precleaning of Reference lists
Summary: When we encounter marking stack overflow during precleaning of Reference lists, we were using the overflow list mechanism, which can cause problems on account of mutating the mark word of the header because of conflicts with mutator accesses and updates of that field. Instead we should use the usual mechanism for overflow handling in concurrent phases, namely dirtying of the card on which the overflowed object lies. Since precleaning effectively does a form of discovered list processing, albeit with discovery enabled, we needed to adjust some code to be correct in the face of interleaved processing and discovery.
Reviewed-by: apetrusenko, jcoomes

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/runtime/globals.hpp

Changeset: c96030fff130
Author:    ysr
Date:      2008-11-20 16:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c96030fff130

6684579: SoftReference processing can be made more efficient
Summary: For current soft-ref clearing policies, we can decide at marking time if a soft-reference will definitely not be cleared, postponing the decision of whether it will definitely be cleared to the final reference processing phase. This can be especially beneficial in the case of concurrent collectors where the marking is usually concurrent but reference processing is usually not.
Reviewed-by: jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/includeDB_core
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/referencePolicy.cpp
! src/share/vm/memory/referencePolicy.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/utilities/macros.hpp

Changeset: df4305d4c1a1
Author:    ysr
Date:      2008-11-24 09:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df4305d4c1a1

6774607: SIGSEGV or (!is_null(v),"oop value can never be zero") assertion when running with CMS and COOPs
Summary: Use the more permissive set_klass_or_null() and klass_or_null() interfaces in ParNew's workqueue overflow code that manipulates the klass-word.
Reviewed-by: coleenp

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/oops/oop.inline.hpp

Changeset: 434912c745cf
Author:    iveresov
Date:      2008-11-26 09:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/434912c745cf

Merge

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



From edilee at gmail.com  Thu Nov 27 22:46:26 2008
From: edilee at gmail.com (Edward Lee)
Date: Fri, 28 Nov 2008 00:46:26 -0600
Subject: C2 Scalar Replacement Behavior?
In-Reply-To: <4921D585.4050700@sun.com>
References: <dc07ed930811171049g279a732bj2c294c6d0d7fbf6@mail.gmail.com>
	<4921D585.4050700@sun.com>
Message-ID: <dc07ed930811272246p7730b4e1n73997f6c96264339@mail.gmail.com>

On Mon, Nov 17, 2008 at 2:35 PM, Vladimir Kozlov
<Vladimir.Kozlov at sun.com> wrote:
> All uses of scalar replaceable object's fields should be replaced
> with values stored into the fields (or with default value 0 if
> there were no stores).
Ah, okay. Thanks. I've been seeing this behavior by setting the
PrintOptoAssembly option for a method through .hotspot_compiler. In
particular, I've been looking at a "pack-and-pass" pattern for short
lifetime objects:

foo(A,B) {
  bar(new pack(A,B))
}

Where the optimized asm has the inlined bar() accessing B directly
(foo's param) with +DoEscapeAnalysis instead of dereferencing an extra
pointer of an allocated pack object.

(Side question, where do I find the structure of Thread::current()? A
quick glance seems to imply [[current() + #68] + #24] is the thread's
allocation bump pointer position and [current() + #76] is perhaps a
allocation watermark where exceeding it slowpaths to
_new_instance_Java. Is this runtime/thread.hpp or is there a simple
way to see what offsets correspond to?)

> We have to keep allocations if optimizer was not able to eliminate
> all loads (for example, volatile fields).
So on the way to macro expand deciding if all the loads of the
allocation have been eliminated, the ideal graph has 2 pairs of nodes:
one using the foo's parameter and another using the allocated pack
object's fields. Assuming an allocation can't be scalar replaced, at
what point does the optimizer drop "use param" and go with "use
alloced object?"

When I turn off -DoEscapeAnalysis, I notice that field references are
again field references even though the value is available through the
parameter. Arguably, the field access needs to be there because
potentially another thread might have changed that newly allocated
object's field. Or is it that optimize_memory_chain wouldn't have
decided to use the param without escape analysis?

Ed