From John.Rose at Sun.COM  Thu Oct  1 00:14:22 2009
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 01 Oct 2009 00:14:22 -0700
Subject: A possible performance boost? (James Ladd)
In-Reply-To: <BLU141-W29C66DD2D610537EE75467EDD30@phx.gbl>
References: <mailman.25.1254164451.22139.mlvm-dev@openjdk.java.net>
	<BLU141-W29C66DD2D610537EE75467EDD30@phx.gbl>
Message-ID: <83049B83-E1AD-4825-8D98-6BBEB661CEA1@sun.com>

On Sep 30, 2009, at 11:41 PM, James Ladd wrote:

> Does anyone see a reason this could not be tried, or has it been  
> tried and what were the results?

Many ideas like this have been tried over the last 12 years.  There  
are engineers working full-time in and with hardware vendors on such  
things.  There is no shortage of clever ideas, only of people to try  
them out and actually demonstrate that they work on real hardware with  
all the actual strange effects of modern caches and pipelines and  
branch predictors.  The way to evaluate a performance idea is to work  
it out in detail and test it on real workloads (not micro-benchmarks).

Until then, I think it's going to work out like Richard Feynman  
observed, "You cannot prove a vague theory wrong."

I would encourage you to build the JVM, run it on something plausible,  
and use a performance analysis tool to find out where the time  
actually goes.  It won't be anywhere near the interpreter, I predict.   
That's historically been the result of interpreter hacking.  You might  
find a bottleneck in compiled code that's worth optimizing.  What I'm  
saying is that performance is determined by compiled code.

There's a similar problem which may interest you, more amenable to  
static analysis, which is to reduce the memory footprint of the JVM.   
For a tiny-footprint JVM, the interpreter performance might be of some  
importance, but the optimization problem is speed + space, rather than  
speed only.

Good luck,
-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091001/a85f28fa/attachment.html 

From yung2.alan at gmail.com  Thu Oct  1 05:33:34 2009
From: yung2.alan at gmail.com (alan yung)
Date: Thu, 1 Oct 2009 05:33:34 -0700
Subject: applying patches doesn't seem to work
In-Reply-To: <358F6155-6B2C-4F3B-B012-30697419B5B0@sun.com>
References: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com>
	<4AC1C446.9090906@Sun.COM>
	<6b6a329a0909290231s3b00c235rebebfc66896711f0@mail.gmail.com>
	<6b6a329a0909300055h38c97880n553697f2a77923d@mail.gmail.com>
	<358F6155-6B2C-4F3B-B012-30697419B5B0@sun.com>
Message-ID: <6b6a329a0910010533r6e673a9cv9e1a68570efbc9c4@mail.gmail.com>

It worked, and I could successfully apply the patches.and, yes it would have
helped! Thanks.

Now I have different build problem - build fails with error messages in
hotspot directory.
The errors look like following:  (the machine is windows XP)

C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\utilities\growableArray.hpp(132)
: error C2220: warn
ing treat
d as error - no 'object' file generated

 C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\utilities\growableArray.hpp(130)
: while com
piling cl
ss template member function 'GrowableArray<E>::GrowableArray(Thread *,int)'
        with
        [
            E=MethodHandleWalker::SlotState
        ]

 c:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\prims\methodHandleWalk.hpp(121)
: see refere
nce to cl
ss template instantiation 'GrowableArray<E>' being compiled
        with
        [
            E=MethodHandleWalker::SlotState
        ]
C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\utilities\growableArray.hpp(132)
: warning C4345: be
havior ch
nge: an object of POD type constructed with an initializer of the form ()
will be default-initialized
C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\utilities\growableArray.hpp(316)
: warning C4345: be
havior ch
nge: an object of POD type constructed with an initializer of the form ()
will be default-initialized

 C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\utilities\growableArray.hpp(307)
: while com
piling cl
ss template member function 'void GrowableArray<E>::grow(int)'
        with
        [
            E=MethodHandleWalker::SlotState
        ]
methodHandles.cpp
nativeLookup.cpp
perf.cpp
privilegedStack.cpp
unsafe.cpp
Generating Code...
NMAKE : fatal error U1077: 'C:\cygwin\home\alan\dtools\msvs\VC\bin\cl.exe' :
return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077:
'C:\cygwin\home\alan\dtools\msvs\VC\bin\nmake.EXE' : return code '0x2'
Stop.
make[1]: *** [generic_build2] Error 2
make[1]: Leaving directory `/home/alan/davinci/sources/hotspot/make'
make: *** [jvmg] Error 2

Any help?  (I'm posting it here since it builds openjdk7 without patches)

Thanks,

alan

On Wed, Sep 30, 2009 at 2:13 PM, John Rose <John.Rose at sun.com> wrote:

> Alan, enclosed is a new section in the README called "Trouble Shooting".
>  Would you mind testing it on your setup, please?  Would it have helped with
> your difficulty?
>
> Thanks,
> -- John
>
> == Trouble Shooting ==
>
> To verify that the current release is properly checked out, you can use
> Mercurial commands like these in the source directory:
>        cd davinci/sources/hotspot
>        hg qpop -a  # following commands assume no patches active
>        hg parent  # output should include the 12-digit hash of the working
> version
>        R_CUR=$(hg parent --template '{node|short}\n')
>        head -1 < .hg/patches/series # header comment describes main base
> revision
>        R_REQ=$(head -1 < .hg/patches/series | awk '{print $4}')  # should
> be main base revision
>        [ $R_REQ = $R_CUR ] || echo "*** WRONG PATCH BASE"
>
> The 'checkout' command can be used to reset a clean source repository to
> the base revision required for patches:
>        hg qpop -a  # following commands assume no patches active
>        hg checkout $R_REQ
>        R_CUR=$(hg parent --template '{node|short}\n')
>        [ $R_REQ = $R_CUR ] || echo "*** CHECKOUT FAILED"
>        hg qselect buildable testable $R_CUR
>        hg qpush -a
>        R_QPAR=$(hg log -r qparent --template '{node|short}\n')
>        [ $R_REQ = $R_QPAR ] || echo "*** QUEUE PUSH FAILED"
>
>
>
> On Sep 30, 2009, at 12:55 AM, alan yung wrote:
>
>  Actually, I didn't apply the patches correctly.
>>
>> Now when I tried to apply the patches, it shows many error messages, but
>> it did apply (at least) some patches successfully.
>>
>> My question is, do the patches apply successfully in current head
>> revision?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091001/2a410c45/attachment.html 

From james_ladd at hotmail.com  Thu Oct  1 15:21:36 2009
From: james_ladd at hotmail.com (James Ladd)
Date: Fri, 2 Oct 2009 08:21:36 +1000
Subject: A possible performance boost? (James Ladd) (John Rose)
In-Reply-To: <mailman.23.1254423602.16208.mlvm-dev@openjdk.java.net>
References: <mailman.23.1254423602.16208.mlvm-dev@openjdk.java.net>
Message-ID: <BLU141-W2700433B894388330022CEDD30@phx.gbl>


Hi John,

Thank you for the response.

Of course I see a lot of merit in what you are suggesting regards benchmarks and
the actual and more pressing concerns.

I do intend to work through a full and proper suite of tests and benchmarks to 
show what if any improvement can be gained. However - in this first instance I 
wanted to broadly check if this hasn't been done before so I am not wasting yours
or my time.

Thanks again for the feedback, it is very helpful.

Rgs, James.
 		 	   		  
_________________________________________________________________
Get the latest news, goss and sport Make ninemsn your homepage!
http://windowslive.ninemsn.com.au/article.aspx?id=813730
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091002/2b2402a5/attachment.html 

From raffaello.giulietti at gmail.com  Fri Oct  2 09:27:10 2009
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 02 Oct 2009 18:27:10 +0200
Subject: NetBeans with mlvm
In-Reply-To: <4ABC6A5F.6020108@gmail.com>
References: <4ABC6A5F.6020108@gmail.com>
Message-ID: <4AC629DE.80804@gmail.com>

No suggestions?

Can I conclude that you either are not using NetBeans or face the same
problems with the IDE and the JDK language extensions like exotic names,
InvokeDynamic, invoke() on MethodHandle, etc.?


Raffaello Giulietti wrote:
> Hello,
> 
> does anybody know how to fool NetBeans' language checker to stick to the
> JDK 7 extensions?
> Or at least how to turn it off to avoid those annoying red underlines
> and the red bullets to the left?
> I'm on version 6.7.1
> 
> Thanks


From Christian.Thalinger at Sun.COM  Fri Oct  2 09:57:43 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Fri, 02 Oct 2009 18:57:43 +0200
Subject: NetBeans with mlvm
In-Reply-To: <4AC629DE.80804@gmail.com>
References: <4ABC6A5F.6020108@gmail.com> <4AC629DE.80804@gmail.com>
Message-ID: <1254502664.10133.5.camel@macbook>

On Fri, 2009-10-02 at 18:27 +0200, Raffaello Giulietti wrote:
> No suggestions?
> 
> Can I conclude that you either are not using NetBeans or face the same
> problems with the IDE and the JDK language extensions like exotic names,
> InvokeDynamic, invoke() on MethodHandle, etc.?

I don't use it, but I remember that John once said something about that.
Not sure if he ever found a way to fix it.

-- Christian


From John.Rose at Sun.COM  Fri Oct  2 14:10:47 2009
From: John.Rose at Sun.COM (John Rose)
Date: Fri, 02 Oct 2009 14:10:47 -0700
Subject: NetBeans with mlvm
In-Reply-To: <1254502664.10133.5.camel@macbook>
References: <4ABC6A5F.6020108@gmail.com> <4AC629DE.80804@gmail.com>
	<1254502664.10133.5.camel@macbook>
Message-ID: <5492E09D-32ED-4A27-BA4E-0D4E66DF796A@sun.com>

On Oct 2, 2009, at 9:57 AM, Christian Thalinger wrote:

> I don't use it, but I remember that John once said something about  
> that.
> Not sure if he ever found a way to fix it.

Yes, I use NB to develop MLVM code all the time.
Please check the links at the end of this post:
   http://blogs.sun.com/jrose/entry/jsr_292_support_in_javac

I use NB6.5; I haven't moved forward from there yet.

-- John

From john.rose at sun.com  Fri Oct  2 17:56:14 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Sat, 03 Oct 2009 00:56:14 +0000
Subject: hg: mlvm/mlvm/jdk: Rebase to bsd-port revision e4ce379ce45d (9/30).
	No code changes.
Message-ID: <20091003005615.128E341986@hg.openjdk.java.net>

Changeset: 0dbc6bc14079
Author:    jrose
Date:      2009-10-02 17:56 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0dbc6bc14079

Rebase to bsd-port revision e4ce379ce45d (9/30).  No code changes.

! series


From john.rose at sun.com  Fri Oct  2 17:56:27 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Sat, 03 Oct 2009 00:56:27 +0000
Subject: hg: mlvm/mlvm/hotspot: Rebase to bsd-port revision 0e916f120466
	(9/29); get compiling on MacOS 10.6.
Message-ID: <20091003005627.C2E2141987@hg.openjdk.java.net>

Changeset: f9a6cda5b465
Author:    jrose
Date:      2009-10-02 17:54 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f9a6cda5b465

Rebase to bsd-port revision 0e916f120466 (9/29); get compiling on MacOS 10.6.

- 6873116.patch
! meth-6815692.patch
! meth.walker.patch
! nonperm-6863023.patch
! series
+ snowleopard.patch


From John.Rose at Sun.COM  Fri Oct  2 18:06:01 2009
From: John.Rose at Sun.COM (John Rose)
Date: Fri, 02 Oct 2009 18:06:01 -0700
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
References: <cfe6b6360909040257u66d8ca43sb42c5ec2c57b5f@mail.gmail.com>
	<20090908155613.GB2084@misty.eyesbeyond.com>
	<fee4d890909131902j5aeab2cew265fd1f2df0cddf1@mail.gmail.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
Message-ID: <F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>

On Oct 1, 2009, at 12:01 PM, John Rose wrote:

> On Oct 1, 2009, at 4:12 AM, Michael Franz wrote:
>
>> Snow Leopard has gcc-4.0 and gcc-4.2.  You can switch for the build
>> by specifying CC=gcc-4.0 and CXX=g++-4.0 before/when calling make.
>
> Yippee!  Looks like I'm back in business on 10.6.  -- John

With the current bsd-port plus unrelated MLVM patches I got a clean  
Snow Leopard build.  It passed the MLVM regression tests.

I had to use GCC 4.0 as Michael suggested.

The 4.2 compiler is offering some porting resistance.  I put a patch  
into MLVM which copes with the new "printf" warnings it generates:
   http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/f9a6cda5b465/snowleopard.patch

This patch is a bunch of lint-type fixes, and works fine on GCC 4.0.   
(Haven't tested on Solaris, etc, but s.b. OK.)  It's probably not  
worth the effort of pushing this patch upstream until we have a  
working GCC 4.2 build.

The current problem with GCC 4.2 is that when I build on x86_32, the  
JVM crashes in at least two places:  Under -Xint mode, the JVMG mode  
throws an assert on exit, and otherwise it throws asserts or crashes  
in compiler-related code.  The 64-bit version of the JVM appears to  
work, but I haven't exercised it much.

Since I'm chasing other problems, I'm going to leave GCC 4.2 alone for  
now.  If anyone wants to pick up this issue, help yourself to  
snowleopard.patch above.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091002/0ef271e2/attachment.html 

From swingler at apple.com  Fri Oct  2 18:29:27 2009
From: swingler at apple.com (Mike Swingler)
Date: Fri, 2 Oct 2009 18:29:27 -0700
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
References: <cfe6b6360909040257u66d8ca43sb42c5ec2c57b5f@mail.gmail.com>
	<20090908155613.GB2084@misty.eyesbeyond.com>
	<fee4d890909131902j5aeab2cew265fd1f2df0cddf1@mail.gmail.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
	<F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
Message-ID: <8F7EDADF-46DE-488A-9534-94760174670E@apple.com>

On Oct 2, 2009, at 6:06 PM, John Rose wrote:

> On Oct 1, 2009, at 12:01 PM, John Rose wrote:
>
>> On Oct 1, 2009, at 4:12 AM, Michael Franz wrote:
>>
>>> Snow Leopard has gcc-4.0 and gcc-4.2.  You can switch for the build
>>> by specifying CC=gcc-4.0 and CXX=g++-4.0 before/when calling make.
>>
>> Yippee!  Looks like I'm back in business on 10.6.  -- John
>
> With the current bsd-port plus unrelated MLVM patches I got a clean  
> Snow Leopard build.  It passed the MLVM regression tests.
>
> I had to use GCC 4.0 as Michael suggested.
>
> The 4.2 compiler is offering some porting resistance.  I put a patch  
> into MLVM which copes with the new "printf" warnings it generates:
>   http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/f9a6cda5b465/snowleopard.patch
>
> This patch is a bunch of lint-type fixes, and works fine on GCC  
> 4.0.  (Haven't tested on Solaris, etc, but s.b. OK.)  It's probably  
> not worth the effort of pushing this patch upstream until we have a  
> working GCC 4.2 build.
>
> The current problem with GCC 4.2 is that when I build on x86_32, the  
> JVM crashes in at least two places:  Under -Xint mode, the JVMG mode  
> throws an assert on exit, and otherwise it throws asserts or crashes  
> in compiler-related code.  The 64-bit version of the JVM appears to  
> work, but I haven't exercised it much.
>
> Since I'm chasing other problems, I'm going to leave GCC 4.2 alone  
> for now.  If anyone wants to pick up this issue, help yourself to  
> snowleopard.patch above.

It might also be worth giving llvm-gcc a try, since that is what we  
use to compile the Java SE 6 in Snow Leopard. It uses gcc's front-end,  
and llvm's code generating back-end. I encountered similar crashes  
using GCC 4.2, and they don't look obvious to isolate, let alone  
resolve.

Mike Swingler
Java Runtime Engineer
Apple Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091002/643a473a/attachment.html 

From John.Rose at Sun.COM  Fri Oct  2 18:47:15 2009
From: John.Rose at Sun.COM (John Rose)
Date: Fri, 02 Oct 2009 18:47:15 -0700
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <8F7EDADF-46DE-488A-9534-94760174670E@apple.com>
References: <cfe6b6360909040257u66d8ca43sb42c5ec2c57b5f@mail.gmail.com>
	<20090908155613.GB2084@misty.eyesbeyond.com>
	<fee4d890909131902j5aeab2cew265fd1f2df0cddf1@mail.gmail.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
	<F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
	<8F7EDADF-46DE-488A-9534-94760174670E@apple.com>
Message-ID: <955BF43A-7A76-456A-89D4-E6C450683E82@Sun.COM>

Thanks for the tip, Mike.  I suppose this is the compiler you mean:  / 
Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2

I can't resist asking:  Will code from llvm-gcc work better with / 
Developer/usr/bin/gdb ?  (Obviously I'm hoping for an easy fix.)

The stack alignment logic on function entry, which gdb appears not to  
know about, makes it hopelessly confused about arguments.  One  
developer I know just switched back to Solaris from Mac because of this.

-- John

On Oct 2, 2009, at 6:29 PM, Mike Swingler wrote:

> It might also be worth giving llvm-gcc a try, since that is what we  
> use to compile the Java SE 6 in Snow Leopard. It uses gcc's front- 
> end, and llvm's code generating back-end. I encountered similar  
> crashes using GCC 4.2, and they don't look obvious to isolate, let  
> alone resolve.


From swingler at apple.com  Sat Oct  3 09:52:10 2009
From: swingler at apple.com (Mike Swingler)
Date: Sat, 3 Oct 2009 09:52:10 -0700
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <955BF43A-7A76-456A-89D4-E6C450683E82@Sun.COM>
References: <cfe6b6360909040257u66d8ca43sb42c5ec2c57b5f@mail.gmail.com>
	<20090908155613.GB2084@misty.eyesbeyond.com>
	<fee4d890909131902j5aeab2cew265fd1f2df0cddf1@mail.gmail.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
	<F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
	<8F7EDADF-46DE-488A-9534-94760174670E@apple.com>
	<955BF43A-7A76-456A-89D4-E6C450683E82@Sun.COM>
Message-ID: <63540B67-4F90-422A-B7C0-7A54D6524FB0@apple.com>

I honestly don't know. I know my personal use of gdb seems to work  
most of the time when I'm debugging the class libraries, but it has no  
idea what the HotSpot frames are. The only other data I have is that  
others have complained bitterly about how confused gdb gets - though I  
guess my use is not sophisticated enough to ever notice it.

Sorry,
~Mike

On Oct 2, 2009, at 6:47 PM, John Rose wrote:

> Thanks for the tip, Mike.  I suppose this is the compiler you  
> mean:  /Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
>
> I can't resist asking:  Will code from llvm-gcc work better with / 
> Developer/usr/bin/gdb ?  (Obviously I'm hoping for an easy fix.)
>
> The stack alignment logic on function entry, which gdb appears not  
> to know about, makes it hopelessly confused about arguments.  One  
> developer I know just switched back to Solaris from Mac because of  
> this.
>
> -- John
>
> On Oct 2, 2009, at 6:29 PM, Mike Swingler wrote:
>
>> It might also be worth giving llvm-gcc a try, since that is what we  
>> use to compile the Java SE 6 in Snow Leopard. It uses gcc's front- 
>> end, and llvm's code generating back-end. I encountered similar  
>> crashes using GCC 4.2, and they don't look obvious to isolate, let  
>> alone resolve.
>


From Christian.Thalinger at Sun.COM  Sun Oct  4 02:39:14 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Sun, 04 Oct 2009 11:39:14 +0200
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
Message-ID: <1254649154.1535.13.camel@macbook>

On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
> I've always found it a bit perplexing that java.lang was never chosen
> for the parent package of the Dynamic API. Why is that? Dynamic types
> are now "part of the language" as proven by spec itself and exotic
> identifiers. Will this be reconsidered?

[I'm forwarding this question to mlvm-dev.]

I think John Rose or another member of the EG should have an answer to
this.

-- Christian


From forax at univ-mlv.fr  Sun Oct  4 04:40:56 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 04 Oct 2009 13:40:56 +0200
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <1254649154.1535.13.camel@macbook>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook>
Message-ID: <4AC889C8.5070208@univ-mlv.fr>

Le 04/10/2009 11:39, Christian Thalinger a ?crit :
> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
>    
>> I've always found it a bit perplexing that java.lang was never chosen
>> for the parent package of the Dynamic API. Why is that? Dynamic types
>> are now "part of the language" as proven by spec itself and exotic
>> identifiers. Will this be reconsidered?
>>      
> [I'm forwarding this question to mlvm-dev.]
>
> I think John Rose or another member of the EG should have an answer to
> this.
>
> -- Christian
>
>    

java.lang => Java the language (not the platform)

Exotic identifiers and MethodHandle.invoke calling rules in Java (the 
language)
are not part of the JSR292 spec.
JSR 292 => method handle API for any (dynamic?) language

So why java.dyn API should be a 'part' of java.lang ?

R?mi

From pbenedict at apache.org  Sun Oct  4 10:11:25 2009
From: pbenedict at apache.org (Paul Benedict)
Date: Sun, 4 Oct 2009 12:11:25 -0500
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <4AC889C8.5070208@univ-mlv.fr>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
Message-ID: <b9e663070910041011y6fd3b2dayee5f352147d7601d@mail.gmail.com>

I thought the language was being modified to make Dynamic<> exempt
from type-checking rules. The way I look at it, grammar is the
underpinnings of language. To "read the grammar" is analogous to
"compiling the source" -- both are about making sense of tokens. With
the introduction of Dynamic<>, I have to amend my understanding of the
grammar to no longer perform type-checking rules. Hence, this is a
language issue.

Did I misunderstand?

Paul

On Sun, Oct 4, 2009 at 6:40 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
> Le 04/10/2009 11:39, Christian Thalinger a ?crit :
>>
>> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
>>
>>>
>>> I've always found it a bit perplexing that java.lang was never chosen
>>> for the parent package of the Dynamic API. Why is that? Dynamic types
>>> are now "part of the language" as proven by spec itself and exotic
>>> identifiers. Will this be reconsidered?
>>>
>>
>> [I'm forwarding this question to mlvm-dev.]
>>
>> I think John Rose or another member of the EG should have an answer to
>> this.
>>
>> -- Christian
>>
>>
>
> java.lang => Java the language (not the platform)
>
> Exotic identifiers and MethodHandle.invoke calling rules in Java (the
> language)
> are not part of the JSR292 spec.
> JSR 292 => method handle API for any (dynamic?) language
>
> So why java.dyn API should be a 'part' of java.lang ?
>
> R?mi
>

From forax at univ-mlv.fr  Sun Oct  4 11:48:28 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 04 Oct 2009 20:48:28 +0200
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <b9e663070910041011y6fd3b2dayee5f352147d7601d@mail.gmail.com>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>	
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
	<b9e663070910041011y6fd3b2dayee5f352147d7601d@mail.gmail.com>
Message-ID: <4AC8EDFC.6060801@univ-mlv.fr>

Le 04/10/2009 19:11, Paul Benedict a ?crit :
> I thought the language was being modified to make Dynamic<>  exempt
> from type-checking rules.

In fact, this is InvokeDynamic.invoke() and MethodHandle.invoke()
that allow you to escape the type-checking rules.

>   The way I look at it, grammar is the
> underpinnings of language. To "read the grammar" is analogous to
> "compiling the source" -- both are about making sense of tokens.

I think you forget 'infer the semantics' somewhere.

>   With
> the introduction of Dynamic<>, I have to amend my understanding of the
> grammar to no longer perform type-checking rules. Hence, this is a
> language issue.
>
> Did I misunderstand?
>
> Paul
>    

There is two specifications :
One is about bringing invokedynamic to the VM,
the JSR292 spec. This spec doesn't require any change to the JLS,
only change to the JVMS.

The other spec is how to allow Java (the language) to use the
invokedynamic/method handle stuff.
Clearly this requires changes of the JLS.
see http://wikis.sun.com/display/mlvm/ProjectCoinProposal

R?mi

From yozh at mx1.ru  Sun Oct  4 16:34:31 2009
From: yozh at mx1.ru (Stepan Koltsov)
Date: Mon, 5 Oct 2009 03:34:31 +0400
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <4AC889C8.5070208@univ-mlv.fr>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
Message-ID: <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com>

On Sun, Oct 4, 2009 at 15:40, R?mi Forax <forax at univ-mlv.fr> wrote:
> Le 04/10/2009 11:39, Christian Thalinger a ?crit :
>> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
>>
>>> I've always found it a bit perplexing that java.lang was never chosen
>>> for the parent package of the Dynamic API. Why is that? Dynamic types
>>> are now "part of the language" as proven by spec itself and exotic
>>> identifiers. Will this be reconsidered?
>>>
>> [I'm forwarding this question to mlvm-dev.]
>>
>> I think John Rose or another member of the EG should have an answer to
>> this.
>>
>> -- Christian
>>
>>
>
> java.lang => Java the language (not the platform)
>
> Exotic identifiers and MethodHandle.invoke calling rules in Java (the
> language)
> are not part of the JSR292 spec.
> JSR 292 => method handle API for any (dynamic?) language
>
> So why java.dyn API should be a 'part' of java.lang ?

java.lang.reflect also deals with JVM objects, not Java language. But
it still java.lang.reflect, not java.reflect.

java.lang.Class is also closer to JVM then to the java language.

java.lang has lots of JVM stuff.

I also think, that package name should be java.lang.dyc, although it
is not absolutely correct.

"java" root package has lots of libraries (java.io, java.sql), and
these libraries should not be mixed with JVM interface.

If you think java.lang.dyn is inappropriate, then java.vm.dyn is
better, because next JVM interface (what ever it will be) can be
placed into java.vm package too and won't be lost among all java.*
stuff.

S.

From pbenedict at apache.org  Sun Oct  4 17:27:58 2009
From: pbenedict at apache.org (Paul Benedict)
Date: Sun, 4 Oct 2009 19:27:58 -0500
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
	<7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com>
Message-ID: <b9e663070910041727n2aa9910jf7e66ca703ba7235@mail.gmail.com>

Stepan,

That is a very good observation. I wonder what others have to say
about it? As you pointed out, there are other java.lang.* sub-packages
that have no impact on the Java language.

I am in agreement that java.dyn is closer to the language than not --
hence I think java.lang.dyn is natural.

Paul

On Sun, Oct 4, 2009 at 6:34 PM, Stepan Koltsov <yozh at mx1.ru> wrote:
> On Sun, Oct 4, 2009 at 15:40, R?mi Forax <forax at univ-mlv.fr> wrote:
>> Le 04/10/2009 11:39, Christian Thalinger a ?crit :
>>> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
>>>
>>>> I've always found it a bit perplexing that java.lang was never chosen
>>>> for the parent package of the Dynamic API. Why is that? Dynamic types
>>>> are now "part of the language" as proven by spec itself and exotic
>>>> identifiers. Will this be reconsidered?
>>>>
>>> [I'm forwarding this question to mlvm-dev.]
>>>
>>> I think John Rose or another member of the EG should have an answer to
>>> this.
>>>
>>> -- Christian
>>>
>>>
>>
>> java.lang => Java the language (not the platform)
>>
>> Exotic identifiers and MethodHandle.invoke calling rules in Java (the
>> language)
>> are not part of the JSR292 spec.
>> JSR 292 => method handle API for any (dynamic?) language
>>
>> So why java.dyn API should be a 'part' of java.lang ?
>
> java.lang.reflect also deals with JVM objects, not Java language. But
> it still java.lang.reflect, not java.reflect.
>
> java.lang.Class is also closer to JVM then to the java language.
>
> java.lang has lots of JVM stuff.
>
> I also think, that package name should be java.lang.dyc, although it
> is not absolutely correct.
>
> "java" root package has lots of libraries (java.io, java.sql), and
> these libraries should not be mixed with JVM interface.
>
> If you think java.lang.dyn is inappropriate, then java.vm.dyn is
> better, because next JVM interface (what ever it will be) can be
> placed into java.vm package too and won't be lost among all java.*
> stuff.
>
> S.
>

From Christian.Thalinger at Sun.COM  Mon Oct  5 05:49:10 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Mon, 05 Oct 2009 14:49:10 +0200
Subject: applying patches doesn't seem to work
In-Reply-To: <6b6a329a0910010533r6e673a9cv9e1a68570efbc9c4@mail.gmail.com>
References: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com>
	<4AC1C446.9090906@Sun.COM>
	<6b6a329a0909290231s3b00c235rebebfc66896711f0@mail.gmail.com>
	<6b6a329a0909300055h38c97880n553697f2a77923d@mail.gmail.com>
	<358F6155-6B2C-4F3B-B012-30697419B5B0@sun.com>
	<6b6a329a0910010533r6e673a9cv9e1a68570efbc9c4@mail.gmail.com>
Message-ID: <1254746950.881.6.camel@macbook>

On Thu, 2009-10-01 at 05:33 -0700, alan yung wrote:
> Now I have different build problem - build fails with error messages
> in hotspot directory.
> The errors look like following:  (the machine is windows XP)
> 
> 
> C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\utilities
> \growableArray.hpp(132) : error C2220: warn
> ing treat
> d as error - no 'object' file generated
>         C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm
> \utilities\growableArray.hpp(130) : while com
> piling cl
> ss template member function 'GrowableArray<E>::GrowableArray(Thread
> *,int)'
>         with
>         [
>             E=MethodHandleWalker::SlotState
>         ]
>         c:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\prims
> \methodHandleWalk.hpp(121) : see refere
> nce to cl
> ss template instantiation 'GrowableArray<E>' being compiled
>         with
>         [
>             E=MethodHandleWalker::SlotState
>         ]
> C:\cygwin\home\alan\davinci\sources\hotspot\src\share\vm\utilities
> \growableArray.hpp(132) : warning C4345: be
> havior ch
> nge: an object of POD type constructed with an initializer of the form
> () will be default-initialized

Sorry for the delay.  This seems to be an initialization problem of a
POD type, changing SlotState to a class should fix the problem.

Currently there is an issue with one of our internal servers, which I
need to push my changes upstream.  You could try to apply the attached
patch yourself, but it may not apply cleanly to your repository.

-- Christian


diff --git a/src/share/vm/prims/methodHandleWalk.cpp b/src/share/vm/prims/methodHandleWalk.cpp
--- a/src/share/vm/prims/methodHandleWalk.cpp
+++ b/src/share/vm/prims/methodHandleWalk.cpp
@@ -227,8 +227,8 @@
 
         for (int i = 0, slot = _outgoing.length() - 1; slot >= 0; slot--) {
           SlotState* arg_state = slot_state(slot);
-          if (arg_state->_type == T_VOID)  continue;
-          ArgToken arg = _outgoing.at(slot)._arg;
+          if (arg_state->type() == T_VOID)  continue;
+          ArgToken arg = _outgoing.at(slot).arg();
 
           klassOop  in_klass  = NULL;
           klassOop  out_klass = NULL;
@@ -264,8 +264,8 @@
         klassOop dest_klass = NULL;
         BasicType dest = java_lang_Class::as_BasicType(chain().adapter_arg_oop(), &dest_klass);
         assert(dest == T_OBJECT, "");
-        assert(dest == arg_state->_type, "");
-        arg_state->_arg = make_conversion(T_OBJECT, dest_klass, Bytecodes::_checkcast, arg_state->_arg, CHECK_(empty));
+        assert(dest == arg_state->type(), "");
+        (void) make_conversion(T_OBJECT, dest_klass, Bytecodes::_checkcast, arg_state->arg(), CHECK_(empty));
         debug_only(dest_klass = (klassOop)badOop);
         break;
       }
@@ -275,7 +275,7 @@
         BasicType src = chain().adapter_conversion_src_type(),
                   dest = chain().adapter_conversion_dest_type();
         Bytecodes::Code bc = conversion_code(src, dest);
-        ArgToken arg = arg_state->_arg;
+        ArgToken arg = arg_state->arg();
         if (bc == Bytecodes::_nop) {
           break;
         } else if (bc != Bytecodes::_illegal) {
@@ -298,7 +298,7 @@
       case sun_dyn_AdapterMethodHandle::OP_REF_TO_PRIM: {
         // checkcast to wrapper type & call intValue, etc.
         BasicType dest = chain().adapter_conversion_dest_type();
-        ArgToken arg = arg_state->_arg;
+        ArgToken arg = arg_state->arg();
         arg = make_conversion(T_OBJECT, SystemDictionary::box_klass(dest),
                               Bytecodes::_checkcast, arg, CHECK_(empty));
         vmIntrinsics::ID unboxer = vmIntrinsics::for_unboxing(dest);
@@ -316,7 +316,7 @@
       case sun_dyn_AdapterMethodHandle::OP_PRIM_TO_REF: {
         // call wrapper type.valueOf
         BasicType src = chain().adapter_conversion_src_type();
-        ArgToken arg = arg_state->_arg;
+        ArgToken arg = arg_state->arg();
         vmIntrinsics::ID boxer = vmIntrinsics::for_boxing(src);
         if (boxer == vmIntrinsics::_none) {
           lose("no boxing method", CHECK_(empty));
@@ -351,7 +351,7 @@
         SlotState* dest_arg_state = slot_state(dest_arg_slot);
         // Rotate the source argument (plus following N slots) into the
         // position occupied by the dest argument (plus following N slots).
-        int rotate_count = type2size[dest_arg_state->_type];
+        int rotate_count = type2size[dest_arg_state->type()];
         // (no other rotate counts are currently supported)
         if (arg_slot < dest_arg_slot) {
           for (int i = 0; i < rotate_count; i++) {
@@ -377,7 +377,7 @@
         for (int i = 0; i < dup_slots; i++) {
           SlotState* dup = slot_state(arg_slot + 2*i);
           if (dup == NULL)              break;  // safety net
-          if (dup->_type != T_VOID)     _outgoing_argc += 1;
+          if (dup->type() != T_VOID)    _outgoing_argc += 1;
           _outgoing.at_insert(i, (*dup));
         }
         break;
@@ -391,7 +391,7 @@
         for (int i = 0; i < drop_slots; i++) {
           SlotState* drop = slot_state(arg_slot);
           if (drop == NULL)             break;  // safety net
-          if (drop->_type != T_VOID)    _outgoing_argc -= 1;
+          if (drop->type() != T_VOID)   _outgoing_argc -= 1;
           _outgoing.remove_at(arg_slot);
         }
         break;
@@ -418,8 +418,8 @@
         debug_only(element_klass_oop = (klassOop)badOop);
 
         // Fetch the argument, which we will cast to the required array type.
-        assert(arg_state->_type == T_OBJECT, "");
-        ArgToken array_arg = arg_state->_arg;
+        assert(arg_state->type() == T_OBJECT, "");
+        ArgToken array_arg = arg_state->arg();
         array_arg = make_conversion(T_OBJECT, array_klass(), Bytecodes::_checkcast, array_arg, CHECK_(empty));
         change_argument(T_OBJECT, arg_slot, T_VOID, ArgToken(tt_void));
 
@@ -506,8 +506,8 @@
   int ap = 0;
   for (int i = _outgoing.length() - 1; i >= 0; i--) {
     SlotState* arg_state = slot_state(i);
-    if (arg_state->_type == T_VOID)  continue;
-    arglist[ap++] = _outgoing.at(i)._arg;
+    if (arg_state->type() == T_VOID)  continue;
+    arglist[ap++] = _outgoing.at(i).arg();
   }
   assert(ap == _outgoing_argc, "");
   arglist[ap] = ArgToken();  // add a sentinel, for the sake of asserts
@@ -566,7 +566,7 @@
     _outgoing.at_put(slot, make_state(new_type, new_arg));
   } else if (old_size > new_size) {
     for (int i = old_size - 1; i >= new_size; i--) {
-      assert((i != 0) == (_outgoing.at(slot + i)._type == T_VOID), "");
+      assert((i != 0) == (_outgoing.at(slot + i).type() == T_VOID), "");
       _outgoing.remove_at(slot + i);
     }
     if (new_size > 0)
@@ -587,7 +587,7 @@
 int MethodHandleWalker::argument_count_slow() {
   int args_seen = 0;
   for (int i = _outgoing.length() - 1; i >= 0; i--) {
-    if (_outgoing.at(i)._type != T_VOID) {
+    if (_outgoing.at(i).type() != T_VOID) {
       ++args_seen;
     }
   }
diff --git a/src/share/vm/prims/methodHandleWalk.hpp b/src/share/vm/prims/methodHandleWalk.hpp
--- a/src/share/vm/prims/methodHandleWalk.hpp
+++ b/src/share/vm/prims/methodHandleWalk.hpp
@@ -145,13 +145,21 @@
   };
 
   // Abstract interpretation state:
-  struct SlotState {
+  class SlotState {
+  private:
     BasicType _type;
     ArgToken  _arg;
+
+  public:
+    SlotState() : _type(T_ILLEGAL) {}
+    SlotState(BasicType type, ArgToken arg) : _type(type), _arg(arg) {}
+
+    BasicType type() const { return _type; }
+    ArgToken  arg()  const { return _arg;  }
   };
+
   static SlotState make_state(BasicType type, ArgToken arg) {
-    SlotState ss;
-    ss._type = type; ss._arg = arg;
+    SlotState ss(type, arg);
     return ss;
   }
 
@@ -178,7 +186,7 @@
     SlotState* ss = slot_state(slot);
     if (ss == NULL)
       return T_ILLEGAL;
-    return ss->_type;
+    return ss->type();
   }
   bool slot_has_argument(int slot) {
     return slot_type(slot) < T_VOID;



From Christian.Thalinger at Sun.COM  Mon Oct  5 09:45:02 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 05 Oct 2009 16:45:02 +0000
Subject: hg: mlvm/mlvm/hotspot: 2 new changesets
Message-ID: <20091005164503.2E77941D95@hg.openjdk.java.net>

Changeset: 5f6b003d2446
Author:    twisti
Date:      2009-10-05 14:30 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5f6b003d2446

indy.compiler.inline: Added missing includes to fix build problem on
Solaris.

! indy.compiler.inline.patch

Changeset: 92135e4f5a67
Author:    twisti
Date:      2009-10-05 15:18 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/92135e4f5a67

indy.compiler.inline: Pass ArgToken as const reference.  This reduces
copies and works around a SS12 compiler bug.

! indy.compiler.inline.patch


From Christian.Thalinger at Sun.COM  Mon Oct  5 09:47:24 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 05 Oct 2009 16:47:24 +0000
Subject: hg: mlvm/mlvm/jdk: series: Updated to 38dbdfe555d0.
Message-ID: <20091005164724.C884341D96@hg.openjdk.java.net>

Changeset: b083645d0526
Author:    twisti
Date:      2009-10-05 18:45 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b083645d0526

series: Updated to 38dbdfe555d0.

! series


From Christian.Thalinger at Sun.COM  Mon Oct  5 09:49:26 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 05 Oct 2009 16:49:26 +0000
Subject: hg: mlvm/mlvm/langtools: series: Updated to be4c695c22cf.
Message-ID: <20091005164926.7DB2641D97@hg.openjdk.java.net>

Changeset: 9197796589d5
Author:    twisti
Date:      2009-10-05 18:46 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/9197796589d5

series: Updated to be4c695c22cf.
meth.patch: Likewise.

! meth.patch
! series


From benjamin.john.evans at googlemail.com  Mon Oct  5 11:01:57 2009
From: benjamin.john.evans at googlemail.com (Ben Evans)
Date: Mon, 5 Oct 2009 19:01:57 +0100
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <b9e663070910041727n2aa9910jf7e66ca703ba7235@mail.gmail.com>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
	<7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com>
	<b9e663070910041727n2aa9910jf7e66ca703ba7235@mail.gmail.com>
Message-ID: <38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com>

I think this is somewhat of a red herring.

After all, there are many classes which live in java.lang which are
fundamental to the operation of the platform, and which any language which
lived on top of the VM would have an intimate relationship with (eg Object,
Class, String, etc).

If we are moving to a point of view in which the Java language is not
central to the platform, but rather first among equals (by removing all
direct dependencies of the JVM spec on the JLS, etc), then in an ideal world
these classes would live in java.core or java.platform or something. That
would of course break the whole world, so is clearly not going to happen.
The best we can do is not make the situation worse for future amendments, by
not placing additional classes which are not specific to the Java language
into java.lang.

I am puzzled, however, by your assertion that dynamic invocation is closer
to the language than 'not', ie closer to the language than the platform.

Non-Java languages have been making use (and shipping support for, in some
cases) of dynamic invocation for quite a few months now. The experience of
those language's implementors has been integral to the development process
of this feature. The Java language has been playing catch-up throughout.
It's fantastic that it's in the JLS now and I look forward to seeing some
first-class implementations of it, but this feature really wasn't crafted
with Java as the pre-eminent use case.

Ben

On Mon, Oct 5, 2009 at 1:27 AM, Paul Benedict <pbenedict at apache.org> wrote:

> Stepan,
>
> That is a very good observation. I wonder what others have to say
> about it? As you pointed out, there are other java.lang.* sub-packages
> that have no impact on the Java language.
>
> I am in agreement that java.dyn is closer to the language than not --
> hence I think java.lang.dyn is natural.
>
> Paul
>
> On Sun, Oct 4, 2009 at 6:34 PM, Stepan Koltsov <yozh at mx1.ru> wrote:
> > On Sun, Oct 4, 2009 at 15:40, R?mi Forax <forax at univ-mlv.fr> wrote:
> >> Le 04/10/2009 11:39, Christian Thalinger a ?crit :
> >>> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
> >>>
> >>>> I've always found it a bit perplexing that java.lang was never chosen
> >>>> for the parent package of the Dynamic API. Why is that? Dynamic types
> >>>> are now "part of the language" as proven by spec itself and exotic
> >>>> identifiers. Will this be reconsidered?
> >>>>
> >>> [I'm forwarding this question to mlvm-dev.]
> >>>
> >>> I think John Rose or another member of the EG should have an answer to
> >>> this.
> >>>
> >>> -- Christian
> >>>
> >>>
> >>
> >> java.lang => Java the language (not the platform)
> >>
> >> Exotic identifiers and MethodHandle.invoke calling rules in Java (the
> >> language)
> >> are not part of the JSR292 spec.
> >> JSR 292 => method handle API for any (dynamic?) language
> >>
> >> So why java.dyn API should be a 'part' of java.lang ?
> >
> > java.lang.reflect also deals with JVM objects, not Java language. But
> > it still java.lang.reflect, not java.reflect.
> >
> > java.lang.Class is also closer to JVM then to the java language.
> >
> > java.lang has lots of JVM stuff.
> >
> > I also think, that package name should be java.lang.dyc, although it
> > is not absolutely correct.
> >
> > "java" root package has lots of libraries (java.io, java.sql), and
> > these libraries should not be mixed with JVM interface.
> >
> > If you think java.lang.dyn is inappropriate, then java.vm.dyn is
> > better, because next JVM interface (what ever it will be) can be
> > placed into java.vm package too and won't be lost among all java.*
> > stuff.
> >
> > S.
> >
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091005/7632eb8f/attachment-0001.html 

From john.rose at sun.com  Mon Oct  5 22:59:12 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 06 Oct 2009 05:59:12 +0000
Subject: hg: mlvm/mlvm/hotspot: dynopt: misc JVM tunings for dynamic languages,
	first cut
Message-ID: <20091006055912.62E4441E6E@hg.openjdk.java.net>

Changeset: 2c52eea63b2d
Author:    jrose
Date:      2009-10-05 22:59 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2c52eea63b2d

dynopt: misc JVM tunings for dynamic languages, first cut

+ dynopt.patch
! series


From Christian.Thalinger at Sun.COM  Tue Oct  6 04:18:50 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 06 Oct 2009 11:18:50 +0000
Subject: hg: mlvm/mlvm/hotspot: 2 new changesets
Message-ID: <20091006111851.25F4641EC5@hg.openjdk.java.net>

Changeset: 315416640f1e
Author:    twisti
Date:      2009-10-06 13:16 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/315416640f1e

meth-6815692, indy-6858164: Fixed typos in
SystemDictionary::initialize_preloaded_classes.

! indy-6858164.patch
! meth-6815692.patch

Changeset: c540582ac5ed
Author:    twisti
Date:      2009-10-06 04:18 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c540582ac5ed

Merge.



From Christian.Thalinger at Sun.COM  Tue Oct  6 04:50:46 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 06 Oct 2009 11:50:46 +0000
Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Disable EA by default for
	EnableInvokeDynamic.
Message-ID: <20091006115046.4869141ECF@hg.openjdk.java.net>

Changeset: b9556526207e
Author:    twisti
Date:      2009-10-06 13:40 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b9556526207e

indy.compiler: Disable EA by default for EnableInvokeDynamic.

! indy.compiler.patch


From Christian.Thalinger at Sun.COM  Tue Oct  6 08:04:58 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 06 Oct 2009 15:04:58 +0000
Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Fixed C1 compilation.
Message-ID: <20091006150459.5AE2F41F04@hg.openjdk.java.net>

Changeset: 65225fbd2833
Author:    twisti
Date:      2009-10-06 17:03 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/65225fbd2833

indy.compiler: Fixed C1 compilation.

! indy.compiler.patch


From forax at univ-mlv.fr  Tue Oct  6 08:07:08 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 06 Oct 2009 17:07:08 +0200
Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Fixed C1 compilation.
In-Reply-To: <20091006150459.5AE2F41F04@hg.openjdk.java.net>
References: <20091006150459.5AE2F41F04@hg.openjdk.java.net>
Message-ID: <4ACB5D1C.4050401@univ-mlv.fr>

Christian.Thalinger at Sun.COM a ?crit :
> Changeset: 65225fbd2833
> Author:    twisti
> Date:      2009-10-06 17:03 +0200
> URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/65225fbd2833
>
> indy.compiler: Fixed C1 compilation.
>
> ! indy.compiler.patch
>   

Hi twisti,
what's the problem between escape analysis and invokedynamic ?

R?mi

From Christian.Thalinger at Sun.COM  Tue Oct  6 08:37:12 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Tue, 06 Oct 2009 17:37:12 +0200
Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Fixed C1 compilation.
In-Reply-To: <4ACB5D1C.4050401@univ-mlv.fr>
References: <20091006150459.5AE2F41F04@hg.openjdk.java.net>
	<4ACB5D1C.4050401@univ-mlv.fr>
Message-ID: <1254843432.885.2.camel@macbook>

On Tue, 2009-10-06 at 17:07 +0200, R?mi Forax wrote:
> Christian.Thalinger at Sun.COM a ?crit :
> > Changeset: 65225fbd2833
> > Author:    twisti
> > Date:      2009-10-06 17:03 +0200
> > URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/65225fbd2833
> >
> > indy.compiler: Fixed C1 compilation.
> >
> > ! indy.compiler.patch
> >   
> 
> Hi twisti,
> what's the problem between escape analysis and invokedynamic ?

The current EA implementation does not take care about invokedynamic and
that leads to asserts.  It simply does not work right now.  We need to
change the implementation, so we disable it for now.

-- Christian


From Christian.Thalinger at Sun.COM  Tue Oct  6 08:39:38 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 06 Oct 2009 15:39:38 +0000
Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Disable compressed oops by
	default.
Message-ID: <20091006153938.C563C41F0E@hg.openjdk.java.net>

Changeset: a7c524d50da1
Author:    twisti
Date:      2009-10-06 17:39 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a7c524d50da1

indy.compiler: Disable compressed oops by default.

! indy.compiler.patch


From Christian.Thalinger at Sun.COM  Tue Oct  6 08:46:57 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 06 Oct 2009 15:46:57 +0000
Subject: hg: mlvm/mlvm/hotspot: dynopt: Added missing includes.
Message-ID: <20091006154657.468AC41F11@hg.openjdk.java.net>

Changeset: b182e3aa7193
Author:    twisti
Date:      2009-10-06 17:46 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b182e3aa7193

dynopt: Added missing includes.

! dynopt.patch


From John.Rose at Sun.COM  Fri Oct  9 08:12:00 2009
From: John.Rose at Sun.COM (John Rose)
Date: Fri, 09 Oct 2009 08:12:00 -0700
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
	<7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com>
	<b9e663070910041727n2aa9910jf7e66ca703ba7235@mail.gmail.com>
	<38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com>
Message-ID: <DE9219A5-D6CF-4FEA-A4BB-EB2D8C1410E9@sun.com>

Thanks, Ben; well said.  Putting a multi-language JVM feature under  
java.lang would be the wrong signal.  OTOH, if we ever do a type  
"Dynamic" in the Java language (a la C#) that would belong in  
java.lang.  But we are not, at present.  (Despite an earlier blog  
proposal of mine!)  JVM changes are a big enough job for now.  -- John

On Oct 5, 2009, at 11:01 AM, Ben Evans wrote:

> I think this is somewhat of a red herring.
>
> After all, there are many classes which live in java.lang which are  
> fundamental to the operation of the platform, and which any language  
> which lived on top of the VM would have an intimate relationship  
> with (eg Object, Class, String, etc).
>
> If we are moving to a point of view in which the Java language is  
> not central to the platform, but rather first among equals (by  
> removing all direct dependencies of the JVM spec on the JLS, etc),  
> then in an ideal world these classes would live in java.core or  
> java.platform or something. That would of course break the whole  
> world, so is clearly not going to happen. The best we can do is not  
> make the situation worse for future amendments, by not placing  
> additional classes which are not specific to the Java language into  
> java.lang.
>
> I am puzzled, however, by your assertion that dynamic invocation is  
> closer to the language than 'not', ie closer to the language than  
> the platform.
>
> Non-Java languages have been making use (and shipping support for,  
> in some cases) of dynamic invocation for quite a few months now. The  
> experience of those language's implementors has been integral to the  
> development process of this feature. The Java language has been  
> playing catch-up throughout. It's fantastic that it's in the JLS now  
> and I look forward to seeing some first-class implementations of it,  
> but this feature really wasn't crafted with Java as the pre-eminent  
> use case.
>
> Ben


From yozh at mx1.ru  Fri Oct  9 19:36:22 2009
From: yozh at mx1.ru (Stepan Koltsov)
Date: Sat, 10 Oct 2009 06:36:22 +0400
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <DE9219A5-D6CF-4FEA-A4BB-EB2D8C1410E9@sun.com>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
	<7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com>
	<b9e663070910041727n2aa9910jf7e66ca703ba7235@mail.gmail.com>
	<38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com>
	<DE9219A5-D6CF-4FEA-A4BB-EB2D8C1410E9@sun.com>
Message-ID: <7c1bea4b0910091936v564b4c15i932831b64061c407@mail.gmail.com>

John, how about multi-language java.lang.Class or java.lang.reflect.Field?

S.


On Fri, Oct 9, 2009 at 19:12, John Rose <John.Rose at sun.com> wrote:
> Thanks, Ben; well said. ?Putting a multi-language JVM feature under
> java.lang would be the wrong signal. ?OTOH, if we ever do a type
> "Dynamic" in the Java language (a la C#) that would belong in
> java.lang. ?But we are not, at present. ?(Despite an earlier blog
> proposal of mine!) ?JVM changes are a big enough job for now. ?-- John
>
> On Oct 5, 2009, at 11:01 AM, Ben Evans wrote:
>
>> I think this is somewhat of a red herring.
>>
>> After all, there are many classes which live in java.lang which are
>> fundamental to the operation of the platform, and which any language
>> which lived on top of the VM would have an intimate relationship
>> with (eg Object, Class, String, etc).
>>
>> If we are moving to a point of view in which the Java language is
>> not central to the platform, but rather first among equals (by
>> removing all direct dependencies of the JVM spec on the JLS, etc),
>> then in an ideal world these classes would live in java.core or
>> java.platform or something. That would of course break the whole
>> world, so is clearly not going to happen. The best we can do is not
>> make the situation worse for future amendments, by not placing
>> additional classes which are not specific to the Java language into
>> java.lang.
>>
>> I am puzzled, however, by your assertion that dynamic invocation is
>> closer to the language than 'not', ie closer to the language than
>> the platform.
>>
>> Non-Java languages have been making use (and shipping support for,
>> in some cases) of dynamic invocation for quite a few months now. The
>> experience of those language's implementors has been integral to the
>> development process of this feature. The Java language has been
>> playing catch-up throughout. It's fantastic that it's in the JLS now
>> and I look forward to seeing some first-class implementations of it,
>> but this feature really wasn't crafted with Java as the pre-eminent
>> use case.
>>
>> Ben
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>

From John.Rose at Sun.COM  Fri Oct  9 19:49:34 2009
From: John.Rose at Sun.COM (John Rose)
Date: Fri, 09 Oct 2009 19:49:34 -0700
Subject: JSR-292: Why not java.lang.dyn?
In-Reply-To: <7c1bea4b0910091936v564b4c15i932831b64061c407@mail.gmail.com>
References: <b9e663070910032143g2ee91bdfo2ce32f157ada787e@mail.gmail.com>
	<1254649154.1535.13.camel@macbook> <4AC889C8.5070208@univ-mlv.fr>
	<7c1bea4b0910041634v1dfda142w62180b779c515cb2@mail.gmail.com>
	<b9e663070910041727n2aa9910jf7e66ca703ba7235@mail.gmail.com>
	<38a53eb30910051101n1cd69750r99455ec8dfc5a6b9@mail.gmail.com>
	<DE9219A5-D6CF-4FEA-A4BB-EB2D8C1410E9@sun.com>
	<7c1bea4b0910091936v564b4c15i932831b64061c407@mail.gmail.com>
Message-ID: <6DCA11A7-65FD-4EC1-A0C4-E81D0D8DBFDB@sun.com>

On Oct 9, 2009, at 7:36 PM, Stepan Koltsov wrote:

> John, how about multi-language java.lang.Class or  
> java.lang.reflect.Field?

How about it?  I don't know how to answer this.  -- John

From john.rose at sun.com  Tue Oct 13 16:48:20 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 13 Oct 2009 23:48:20 +0000
Subject: hg: mlvm/mlvm: 3 new changesets
Message-ID: <20091013234821.0148C41455@hg.openjdk.java.net>

Changeset: 7c3f96e3b7f0
Author:    jrose
Date:      2009-10-12 01:22 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/7c3f96e3b7f0

clarify instructions

! README.txt

Changeset: b3c0a99a49f6
Author:    jrose
Date:      2009-10-12 16:27 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/b3c0a99a49f6

jtreg supports junit

+ jtreg/jtreg-no-junit.zip
+ jtreg/junitsupport.patch
+ jtreg/junitsupport.txt

Changeset: 912e00503502
Author:    jrose
Date:      2009-10-12 16:30 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/912e00503502

update projects to API tweaks

! netbeans/indy-demo/build.xml
! netbeans/indy-demo/nbproject/project.properties
! netbeans/indy-demo/src/recipes/Curry.java
! netbeans/indy-demo/src/recipes/FastAndSlow.java
! netbeans/meth/nbproject/project.properties
! netbeans/meth/test/jdk/java/dyn/MethodHandlesTest.java


From john.rose at sun.com  Tue Oct 13 16:59:04 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 13 Oct 2009 23:59:04 +0000
Subject: hg: mlvm/mlvm/jdk: 2 new changesets
Message-ID: <20091013235905.1A1B141458@hg.openjdk.java.net>

Changeset: 7d84880ce846
Author:    jrose
Date:      2009-10-12 16:33 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7d84880ce846

add first junit-based test

! indy.tests.patch

Changeset: 62eb8b60009c
Author:    jrose
Date:      2009-10-13 16:58 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/62eb8b60009c

Merge



From john.rose at sun.com  Wed Oct 14 18:07:49 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 15 Oct 2009 01:07:49 +0000
Subject: hg: mlvm/mlvm: jtreg bug fixes; passes self-test cleanly
Message-ID: <20091015010749.9B44141654@hg.openjdk.java.net>

Changeset: 7caa97f6f7b6
Author:    jrose
Date:      2009-10-14 18:06 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/7caa97f6f7b6

jtreg bug fixes; passes self-test cleanly

! jtreg/jtreg-no-junit.zip
! jtreg/junitsupport.patch


From john.rose at sun.com  Wed Oct 14 23:51:53 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 15 Oct 2009 06:51:53 +0000
Subject: hg: mlvm/mlvm/jdk: anonk: jtreg test passes
Message-ID: <20091015065153.4A7EA416B6@hg.openjdk.java.net>

Changeset: d00b8a6cb261
Author:    jrose
Date:      2009-10-14 23:51 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/d00b8a6cb261

anonk: jtreg test passes

! indy.tests.patch


From john.rose at sun.com  Thu Oct 15 01:32:56 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 15 Oct 2009 08:32:56 +0000
Subject: hg: mlvm/mlvm/jdk: indy.tests.patch: junit test senses which platform
	is being tested
Message-ID: <20091015083256.81C66416D1@hg.openjdk.java.net>

Changeset: 59d1b2ab1952
Author:    jrose
Date:      2009-10-15 01:32 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/59d1b2ab1952

indy.tests.patch: junit test senses which platform is being tested

! indy.tests.patch


From Christian.Thalinger at Sun.COM  Fri Oct 16 06:12:40 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Fri, 16 Oct 2009 13:12:40 +0000
Subject: hg: mlvm/mlvm/hotspot: 2 new changesets
Message-ID: <20091016131240.9B663418E1@hg.openjdk.java.net>

Changeset: f3e40ccd4013
Author:    twisti
Date:      2009-10-16 15:11 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f3e40ccd4013

indy.compiler: Bugfixes.

! indy.compiler.patch

Changeset: e7a1bf054a6c
Author:    twisti
Date:      2009-10-16 15:12 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e7a1bf054a6c

indy.compiler.inline: Bugfixes.

! indy.compiler.inline.patch


From Christian.Thalinger at Sun.COM  Fri Oct 16 07:31:22 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Fri, 16 Oct 2009 14:31:22 +0000
Subject: hg: mlvm/mlvm/hotspot: 2 new changesets
Message-ID: <20091016143122.A05AB418F6@hg.openjdk.java.net>

Changeset: f2f1db50dd5d
Author:    twisti
Date:      2009-10-16 16:07 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f2f1db50dd5d

indy.compiler: Fixed 64-bit debug compilation problem.

! indy.compiler.patch

Changeset: bdb62f871e2c
Author:    twisti
Date:      2009-10-16 16:07 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/bdb62f871e2c

indy.compiler.inline: Fixed CHECK return value.

! indy.compiler.inline.patch


From glewis at eyesbeyond.com  Sun Oct 18 13:06:36 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Sun, 18 Oct 2009 13:06:36 -0700
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
References: <cfe6b6360909040257u66d8ca43sb42c5ec2c57b5f@mail.gmail.com>
	<20090908155613.GB2084@misty.eyesbeyond.com>
	<fee4d890909131902j5aeab2cew265fd1f2df0cddf1@mail.gmail.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
	<F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
Message-ID: <20091018200636.GA54675@misty.eyesbeyond.com>

G'day John,

On Fri, Oct 02, 2009 at 06:06:01PM -0700, John Rose wrote:
> With the current bsd-port plus unrelated MLVM patches I got a clean  
> Snow Leopard build.  It passed the MLVM regression tests.
> 
> I had to use GCC 4.0 as Michael suggested.
> 
> The 4.2 compiler is offering some porting resistance.  I put a patch  
> into MLVM which copes with the new "printf" warnings it generates:
>    http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/f9a6cda5b465/snowleopard.patch

Looking at the patch, it defines FORMATL32_MODIFIER for all gcc >= 4.2.
Interestingly, FreeBSD (7.x) uses gcc 4.2.1 and doesn't have any problem
compiling HotSpot (its my main platform).  So perhaps this is overly
broad?  I'll give the patch a try and see if it causes any compile
problems.  If so then we probably want to restrict this to just MacOS X
and not all platforms in general.

I'd like to push this in before I start the b74 merge (just pushing the
b73 merge now).

> This patch is a bunch of lint-type fixes, and works fine on GCC 4.0.   
> (Haven't tested on Solaris, etc, but s.b. OK.)  It's probably not  
> worth the effort of pushing this patch upstream until we have a  
> working GCC 4.2 build.
> 
> The current problem with GCC 4.2 is that when I build on x86_32, the  
> JVM crashes in at least two places:  Under -Xint mode, the JVMG mode  
> throws an assert on exit, and otherwise it throws asserts or crashes  
> in compiler-related code.  The 64-bit version of the JVM appears to  
> work, but I haven't exercised it much.

FreeBSD 7.x/i386 doesn't exhibit these problems with gcc 4.2.1, so it
seems to be something specific to either MacOS X or Apple's version of
gcc 4.2.

> Since I'm chasing other problems, I'm going to leave GCC 4.2 alone for  
> now.  If anyone wants to pick up this issue, help yourself to  
> snowleopard.patch above.
> 
> -- John

> 


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

From glewis at eyesbeyond.com  Sun Oct 18 20:38:55 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Sun, 18 Oct 2009 20:38:55 -0700
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <20091018200636.GA54675@misty.eyesbeyond.com>
References: <20090908155613.GB2084@misty.eyesbeyond.com>
	<fee4d890909131902j5aeab2cew265fd1f2df0cddf1@mail.gmail.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
	<F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
	<20091018200636.GA54675@misty.eyesbeyond.com>
Message-ID: <20091019033855.GA65999@misty.eyesbeyond.com>

G'day John,

On Sun, Oct 18, 2009 at 01:06:36PM -0700, Greg Lewis wrote:
> On Fri, Oct 02, 2009 at 06:06:01PM -0700, John Rose wrote:
> > With the current bsd-port plus unrelated MLVM patches I got a clean  
> > Snow Leopard build.  It passed the MLVM regression tests.
> > 
> > I had to use GCC 4.0 as Michael suggested.
> > 
> > The 4.2 compiler is offering some porting resistance.  I put a patch  
> > into MLVM which copes with the new "printf" warnings it generates:
> >    http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/f9a6cda5b465/snowleopard.patch
> 
> Looking at the patch, it defines FORMATL32_MODIFIER for all gcc >= 4.2.
> Interestingly, FreeBSD (7.x) uses gcc 4.2.1 and doesn't have any problem
> compiling HotSpot (its my main platform).  So perhaps this is overly
> broad?  I'll give the patch a try and see if it causes any compile
> problems.  If so then we probably want to restrict this to just MacOS X
> and not all platforms in general.

Following up my own email...

I did do a test compile without any problems on FreeBSD.  Looking further
at the patch I have to wonder why the OpenJDK code is essentially doing a
mini version of the printf defines from <inttypes.h>.  Thats a standard
C99 header file, so why not just use the defines there?  E.g. just use
PRIdPTR instead of the JVM defining its own PTR_FORMAT.

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

From gnu_andrew at member.fsf.org  Mon Oct 19 01:59:51 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 19 Oct 2009 09:59:51 +0100
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <20091019033855.GA65999@misty.eyesbeyond.com>
References: <20090908155613.GB2084@misty.eyesbeyond.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
	<F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
	<20091018200636.GA54675@misty.eyesbeyond.com>
	<20091019033855.GA65999@misty.eyesbeyond.com>
Message-ID: <17c6771e0910190159x4ec24ceax50b1b99e54e541d0@mail.gmail.com>

2009/10/19 Greg Lewis <glewis at eyesbeyond.com>:
> G'day John,
>
> On Sun, Oct 18, 2009 at 01:06:36PM -0700, Greg Lewis wrote:
>> On Fri, Oct 02, 2009 at 06:06:01PM -0700, John Rose wrote:
>> > With the current bsd-port plus unrelated MLVM patches I got a clean
>> > Snow Leopard build. ?It passed the MLVM regression tests.
>> >
>> > I had to use GCC 4.0 as Michael suggested.
>> >
>> > The 4.2 compiler is offering some porting resistance. ?I put a patch
>> > into MLVM which copes with the new "printf" warnings it generates:
>> > ? ?http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/f9a6cda5b465/snowleopard.patch
>>
>> Looking at the patch, it defines FORMATL32_MODIFIER for all gcc >= 4.2.
>> Interestingly, FreeBSD (7.x) uses gcc 4.2.1 and doesn't have any problem
>> compiling HotSpot (its my main platform). ?So perhaps this is overly
>> broad? ?I'll give the patch a try and see if it causes any compile
>> problems. ?If so then we probably want to restrict this to just MacOS X
>> and not all platforms in general.
>
> Following up my own email...
>
> I did do a test compile without any problems on FreeBSD. ?Looking further
> at the patch I have to wonder why the OpenJDK code is essentially doing a
> mini version of the printf defines from <inttypes.h>. ?Thats a standard
> C99 header file, so why not just use the defines there? ?E.g. just use
> PRIdPTR instead of the JVM defining its own PTR_FORMAT.
>
> --
> Greg Lewis ? ? ? ? ? ? ? ? ? ? ? ? ?Email ? : glewis at eyesbeyond.com
> Eyes Beyond ? ? ? ? ? ? ? ? ? ? ? ? Web ? ? : http://www.eyesbeyond.com
> Information Technology ? ? ? ? ? ? ?FreeBSD : glewis at FreeBSD.org
>
>


I know, from recent discussions, that C99 has been avoided in some
cases because the Windows compiler doesn't support it, resulting in
similar local definitions and hacks.  This may also be the case here.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

From Christian.Thalinger at Sun.COM  Mon Oct 19 11:18:54 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 19 Oct 2009 18:18:54 +0000
Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Bugfix for 64-bit x86.
Message-ID: <20091019181855.50FB341DAE@hg.openjdk.java.net>

Changeset: b6483b8fa46e
Author:    twisti
Date:      2009-10-19 20:16 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b6483b8fa46e

indy.compiler: Bugfix for 64-bit x86.

! indy.compiler.patch


From Christian.Thalinger at Sun.COM  Tue Oct 20 04:18:52 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 20 Oct 2009 11:18:52 +0000
Subject: hg: mlvm/mlvm/hotspot: indy-cleanup-6893081: Changes from
	indy.compiler.patch that should be commited seperately.
Message-ID: <20091020111852.A52A141EC6@hg.openjdk.java.net>

Changeset: f770a5d6ca97
Author:    twisti
Date:      2009-10-20 13:17 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f770a5d6ca97

indy-cleanup-6893081: Changes from indy.compiler.patch that should be commited seperately.
indy.compiler: Sans 6893081.

+ indy-cleanup-6893081.patch
! indy.compiler.patch
! series


From Christian.Thalinger at Sun.COM  Tue Oct 20 07:54:24 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 20 Oct 2009 14:54:24 +0000
Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Fixed last_sp assert properly.
Message-ID: <20091020145424.682A041F00@hg.openjdk.java.net>

Changeset: f7dc86566a0e
Author:    twisti
Date:      2009-10-20 16:52 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f7dc86566a0e

indy.compiler: Fixed last_sp assert properly.

! indy.compiler.patch


From raffaello.giulietti at gmail.com  Tue Oct 20 07:57:25 2009
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Tue, 20 Oct 2009 16:57:25 +0200
Subject: good platform to build da Vinci on?
Message-ID: <4ADDCFD5.50703@gmail.com>

Hello,

each time I download a newer da Vinci repository on my (virtual) Ubuntu,
I also get newer build error to chase and adjust. This is becoming
tedious, error-prone and requires too much time. Further, it doesn't
directly contribute to my project which consists in *using* the JVM
extensions to implement a dynamic language on top of the mlvm.

So, rather than insisting with Ubuntu, I'm ready to switch to
(Open)Solaris (32 bits) instead and give up my attempts to build on Linux.

Does anybody have experience with building da Vinci on (Open)Solaris?
Does it goes easily and without troubles? Are there special issues to
take into account?

Thank you all in advance
Raffaello



P.S.
I'd really like to go with FreeBSD but that's a poorly supported
VirtualBox guest. I've a 32 bits Windows host, no hope for more.

From Christian.Thalinger at Sun.COM  Tue Oct 20 08:03:30 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Tue, 20 Oct 2009 17:03:30 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <4ADDCFD5.50703@gmail.com>
References: <4ADDCFD5.50703@gmail.com>
Message-ID: <1256051010.820.103.camel@macbook>

On Tue, 2009-10-20 at 16:57 +0200, Raffaello Giulietti wrote:
> Hello,
> 
> each time I download a newer da Vinci repository on my (virtual) Ubuntu,
> I also get newer build error to chase and adjust. This is becoming
> tedious, error-prone and requires too much time. Further, it doesn't
> directly contribute to my project which consists in *using* the JVM
> extensions to implement a dynamic language on top of the mlvm.
> 
> So, rather than insisting with Ubuntu, I'm ready to switch to
> (Open)Solaris (32 bits) instead and give up my attempts to build on Linux.
> 
> Does anybody have experience with building da Vinci on (Open)Solaris?
> Does it goes easily and without troubles? Are there special issues to
> take into account?

Yes, I'm building mlvm (well, HotSpot) on OpenSolaris everyday and there
are no troubles.  There could be some build problems with the newest Sun
Studio version shipped in OpenSolaris, but I guess not.

-- Christian


From raffaello.giulietti at gmail.com  Tue Oct 20 08:31:16 2009
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Tue, 20 Oct 2009 17:31:16 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <1256051010.820.103.camel@macbook>
References: <4ADDCFD5.50703@gmail.com> <1256051010.820.103.camel@macbook>
Message-ID: <4ADDD7C4.3060705@gmail.com>

Christian Thalinger wrote:
> On Tue, 2009-10-20 at 16:57 +0200, Raffaello Giulietti wrote:
>> Hello,
>>
>> each time I download a newer da Vinci repository on my (virtual) Ubuntu,
>> I also get newer build error to chase and adjust. This is becoming
>> tedious, error-prone and requires too much time. Further, it doesn't
>> directly contribute to my project which consists in *using* the JVM
>> extensions to implement a dynamic language on top of the mlvm.
>>
>> So, rather than insisting with Ubuntu, I'm ready to switch to
>> (Open)Solaris (32 bits) instead and give up my attempts to build on Linux.
>>
>> Does anybody have experience with building da Vinci on (Open)Solaris?
>> Does it goes easily and without troubles? Are there special issues to
>> take into account?
> 
> Yes, I'm building mlvm (well, HotSpot) on OpenSolaris everyday and there
> are no troubles.  There could be some build problems with the newest Sun
> Studio version shipped in OpenSolaris, but I guess not.
> 
> -- Christian
> 

Nice to hear!

Tomorrow I'll start afresh with OpenSolaris/VirtualBox.


From john.rose at sun.com  Tue Oct 20 15:47:42 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 20 Oct 2009 22:47:42 +0000
Subject: hg: mlvm/mlvm: patches from jtreg 4.1 RC
Message-ID: <20091020224742.ECA9841F84@hg.openjdk.java.net>

Changeset: d02552d5c1bd
Author:    jrose
Date:      2009-10-20 15:47 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/d02552d5c1bd

patches from jtreg 4.1 RC

! jtreg/jtreg-no-junit.zip
! jtreg/junitsupport.patch
! jtreg/junitsupport.txt


From john.rose at sun.com  Tue Oct 20 15:50:48 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 20 Oct 2009 22:50:48 +0000
Subject: hg: mlvm/mlvm/jdk: indy: factor out initial tests for 6891770
Message-ID: <20091020225048.91B2341F86@hg.openjdk.java.net>

Changeset: 57a31b0f8ef6
Author:    jrose
Date:      2009-10-20 15:50 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/57a31b0f8ef6

indy: factor out initial tests for 6891770

! indy.tests.patch
+ regtest-6891770.patch
! series


From John.Rose at Sun.COM  Tue Oct 20 23:23:39 2009
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 20 Oct 2009 23:23:39 -0700
Subject: OpenJDK 7 build fails on Snow Leopard
In-Reply-To: <20091018200636.GA54675@misty.eyesbeyond.com>
References: <cfe6b6360909040257u66d8ca43sb42c5ec2c57b5f@mail.gmail.com>
	<20090908155613.GB2084@misty.eyesbeyond.com>
	<fee4d890909131902j5aeab2cew265fd1f2df0cddf1@mail.gmail.com>
	<20090914030426.GA4179@misty.eyesbeyond.com>
	<fee4d890909132010k3e9e49e7ha3d0e23364ae2e93@mail.gmail.com>
	<fee4d890909141539p2f6b4ce4h2518ad9ece9190bc@mail.gmail.com>
	<104AA51C-6EC5-441C-9EED-3EF6777AD15C@sun.com>
	<fee4d890910010412j10e93476p99d7fbb8374e9169@mail.gmail.com>
	<DCC4AFE3-6720-476B-BC23-68A773259E07@Sun.COM>
	<F52624F5-7FBB-4FFC-870C-6DBE832BC090@sun.com>
	<20091018200636.GA54675@misty.eyesbeyond.com>
Message-ID: <C3BF6772-0C9D-4CCF-B793-BF4C05BB4495@Sun.COM>

On Oct 18, 2009, at 1:06 PM, Greg Lewis wrote:

> G'day John,
>
> On Fri, Oct 02, 2009 at 06:06:01PM -0700, John Rose wrote:
>> With the current bsd-port plus unrelated MLVM patches I got a clean
>> Snow Leopard build.  It passed the MLVM regression tests.
>>
>> I had to use GCC 4.0 as Michael suggested.
>>
>> The 4.2 compiler is offering some porting resistance.  I put a patch
>> into MLVM which copes with the new "printf" warnings it generates:
>>   http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/f9a6cda5b465/snowleopard.patch
>
> Looking at the patch, it defines FORMATL32_MODIFIER for all gcc >=  
> 4.2.
> Interestingly, FreeBSD (7.x) uses gcc 4.2.1 and doesn't have any  
> problem
> compiling HotSpot (its my main platform).  So perhaps this is overly
> broad?  I'll give the patch a try and see if it causes any compile
> problems.  If so then we probably want to restrict this to just  
> MacOS X
> and not all platforms in general.

I only tried the 4.0 and 4.2 on my Mac, so it could well be overly  
broad.

> I'd like to push this in before I start the b74 merge (just pushing  
> the
> b73 merge now).
>
>> This patch is a bunch of lint-type fixes, and works fine on GCC 4.0.
>> (Haven't tested on Solaris, etc, but s.b. OK.)  It's probably not
>> worth the effort of pushing this patch upstream until we have a
>> working GCC 4.2 build.
>>
>> The current problem with GCC 4.2 is that when I build on x86_32, the
>> JVM crashes in at least two places:  Under -Xint mode, the JVMG mode
>> throws an assert on exit, and otherwise it throws asserts or crashes
>> in compiler-related code.  The 64-bit version of the JVM appears to
>> work, but I haven't exercised it much.
>
> FreeBSD 7.x/i386 doesn't exhibit these problems with gcc 4.2.1, so it
> seems to be something specific to either MacOS X or Apple's version of
> gcc 4.2.

That's good to know.  As a "lint" type check, it seems excessively  
picky.

The patch is *not* needed to build hotspot, even on snow leopard, as  
long as gcc 4.2 is avoided.
I published it in case someone wants to try to track down the other  
problems with gcc 4.2.

Thanks for looking it over!

-- John

>> Since I'm chasing other problems, I'm going to leave GCC 4.2 alone  
>> for
>> now.  If anyone wants to pick up this issue, help yourself to
>> snowleopard.patch above.
>>
>> -- John
>
>>
>
>
> -- 
> Greg Lewis                          Email   : glewis at eyesbeyond.com
> Eyes Beyond                         Web     : http:// 
> www.eyesbeyond.com
> Information Technology              FreeBSD : glewis at FreeBSD.org
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From Christian.Thalinger at Sun.COM  Wed Oct 21 05:39:26 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Wed, 21 Oct 2009 12:39:26 +0000
Subject: hg: mlvm/mlvm/langtools: Rebase to bsd-port jdk7-b74.
Message-ID: <20091021123926.5F48441400@hg.openjdk.java.net>

Changeset: cd553e8abd82
Author:    twisti
Date:      2009-10-21 14:34 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/cd553e8abd82

Rebase to bsd-port jdk7-b74.

! series


From Christian.Thalinger at Sun.COM  Wed Oct 21 05:39:16 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Wed, 21 Oct 2009 12:39:16 +0000
Subject: hg: mlvm/mlvm/jdk: Rebase to bsd-port jdk7-b74.
Message-ID: <20091021123916.276A3413FE@hg.openjdk.java.net>

Changeset: c559205cb244
Author:    twisti
Date:      2009-10-21 14:34 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/c559205cb244

Rebase to bsd-port jdk7-b74.

! series


From Christian.Thalinger at Sun.COM  Wed Oct 21 05:38:56 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Wed, 21 Oct 2009 12:38:56 +0000
Subject: hg: mlvm/mlvm/hotspot: Rebase to bsd-port jdk7-b74.
Message-ID: <20091021123856.AA139413FC@hg.openjdk.java.net>

Changeset: 676b97131183
Author:    twisti
Date:      2009-10-21 14:33 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/676b97131183

Rebase to bsd-port jdk7-b74.

! indy-6858164.patch
! indy-cleanup-6893081.patch
- nonperm-6863023.patch
! series


From Christian.Thalinger at Sun.COM  Wed Oct 21 06:07:01 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Wed, 21 Oct 2009 13:07:01 +0000
Subject: hg: mlvm/mlvm/hotspot: dynopt: Updated to jdk7-b74.
Message-ID: <20091021130701.A2B2F4140A@hg.openjdk.java.net>

Changeset: 1fadccb2002c
Author:    twisti
Date:      2009-10-21 15:05 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1fadccb2002c

dynopt: Updated to jdk7-b74.
indy-6858164: Fixed typo.

! dynopt.patch
! indy-6858164.patch


From Christian.Thalinger at Sun.COM  Wed Oct 21 06:22:19 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Wed, 21 Oct 2009 15:22:19 +0200
Subject: hg: mlvm/mlvm/hotspot: dynopt: Updated to jdk7-b74.
In-Reply-To: <20091021130701.A2B2F4140A@hg.openjdk.java.net>
References: <20091021130701.A2B2F4140A@hg.openjdk.java.net>
Message-ID: <1256131339.21356.1.camel@macbook>

On Wed, 2009-10-21 at 13:07 +0000, Christian.Thalinger at Sun.COM wrote:
> Changeset: 1fadccb2002c
> Author:    twisti
> Date:      2009-10-21 15:05 +0200
> URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1fadccb2002c
> 
> dynopt: Updated to jdk7-b74.
> indy-6858164: Fixed typo.
> 
> ! dynopt.patch

dynopt.patch is still broken.  Please don't apply it!

-- Christian


From raffaello.giulietti at gmail.com  Wed Oct 21 09:09:11 2009
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 21 Oct 2009 18:09:11 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <1256051010.820.103.camel@macbook>
References: <4ADDCFD5.50703@gmail.com> <1256051010.820.103.camel@macbook>
Message-ID: <4ADF3227.4050608@gmail.com>

Christian Thalinger wrote:
> On Tue, 2009-10-20 at 16:57 +0200, Raffaello Giulietti wrote:
>> Hello,
>>
>> each time I download a newer da Vinci repository on my (virtual) Ubuntu,
>> I also get newer build error to chase and adjust. This is becoming
>> tedious, error-prone and requires too much time. Further, it doesn't
>> directly contribute to my project which consists in *using* the JVM
>> extensions to implement a dynamic language on top of the mlvm.
>>
>> So, rather than insisting with Ubuntu, I'm ready to switch to
>> (Open)Solaris (32 bits) instead and give up my attempts to build on Linux.
>>
>> Does anybody have experience with building da Vinci on (Open)Solaris?
>> Does it goes easily and without troubles? Are there special issues to
>> take into account?
> 
> Yes, I'm building mlvm (well, HotSpot) on OpenSolaris everyday and there
> are no troubles.  There could be some build problems with the newest Sun
> Studio version shipped in OpenSolaris, but I guess not.
> 
> -- Christian
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Hi Christian,

I'm having troubles with mercurial's own mq extensions.

I just installed OpenSolaris and extended it according to the general
OpenJDK build instructions, then added mercurial and the forest
extensions. But while the forest extensions work flawlessly (I could
download da Vinci), the mq extensions do not, although they should come
preinstalled. And yes, the flags are configured in the .hgrc file
according to the build instructions of the mlvm (I tried both mq= and
hgext.mq=).

Did you (or anybody watching) encounter similar problems with
mercurial/OpenSolaris.2009-06?

Thanks
Raffaello

From Christian.Thalinger at Sun.COM  Wed Oct 21 09:43:52 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Wed, 21 Oct 2009 16:43:52 +0000
Subject: hg: mlvm/mlvm/hotspot: meth.walker: Fix for solaris fastdebug builds.
Message-ID: <20091021164353.2A8ED4144F@hg.openjdk.java.net>

Changeset: a6bbb7f54c50
Author:    twisti
Date:      2009-10-21 18:42 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a6bbb7f54c50

meth.walker: Fix for solaris fastdebug builds.

! meth.walker.patch


From Christian.Thalinger at Sun.COM  Wed Oct 21 11:04:46 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Wed, 21 Oct 2009 20:04:46 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <4ADF3227.4050608@gmail.com>
References: <4ADDCFD5.50703@gmail.com> <1256051010.820.103.camel@macbook>
	<4ADF3227.4050608@gmail.com>
Message-ID: <1256148286.21356.31.camel@macbook>

On Wed, 2009-10-21 at 18:09 +0200, Raffaello Giulietti wrote:
> Hi Christian,
> 
> I'm having troubles with mercurial's own mq extensions.
> 
> I just installed OpenSolaris and extended it according to the general
> OpenJDK build instructions, then added mercurial and the forest
> extensions. But while the forest extensions work flawlessly (I could
> download da Vinci), the mq extensions do not, although they should come
> preinstalled. And yes, the flags are configured in the .hgrc file
> according to the build instructions of the mlvm (I tried both mq= and
> hgext.mq=).
> 
> Did you (or anybody watching) encounter similar problems with
> mercurial/OpenSolaris.2009-06?

No, never had problems with it.  Do you have the mq.py file?

twisti at macbook:~$ grep mq .hgrc
mq =
twisti at macbook:~$ ls -l /usr/lib/python2.4/vendor-packages/hgext/mq.py
-r--r--r-- 1 root bin 97773 2009-07-23 19:58 /usr/lib/python2.4/vendor-packages/hgext/mq.py

-- Christian


From Christian.Thalinger at Sun.COM  Wed Oct 21 11:21:53 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Wed, 21 Oct 2009 18:21:53 +0000
Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Updated to apply cleanly.
Message-ID: <20091021182153.B8DB841400@hg.openjdk.java.net>

Changeset: 9be5471b12f0
Author:    twisti
Date:      2009-10-21 20:21 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9be5471b12f0

indy.compiler.inline: Updated to apply cleanly.

! indy.compiler.inline.patch


From john.rose at sun.com  Wed Oct 21 23:13:08 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 22 Oct 2009 06:13:08 +0000
Subject: hg: mlvm/mlvm/jdk: renumber indy.patch
Message-ID: <20091022061309.1418C414DE@hg.openjdk.java.net>

Changeset: ec104f2c904e
Author:    jrose
Date:      2009-10-21 23:13 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ec104f2c904e

renumber indy.patch

+ indy-6858164.patch
! indy.patch
! meth.patch
! regtest-6891770.patch


From raffaello.giulietti at gmail.com  Thu Oct 22 01:56:24 2009
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 22 Oct 2009 10:56:24 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <1256148286.21356.31.camel@macbook>
References: <4ADDCFD5.50703@gmail.com>
	<1256051010.820.103.camel@macbook>	<4ADF3227.4050608@gmail.com>
	<1256148286.21356.31.camel@macbook>
Message-ID: <4AE01E38.1040303@gmail.com>

Christian Thalinger wrote:
> On Wed, 2009-10-21 at 18:09 +0200, Raffaello Giulietti wrote:
>> Hi Christian,
>>
>> I'm having troubles with mercurial's own mq extensions.
>>
>> I just installed OpenSolaris and extended it according to the general
>> OpenJDK build instructions, then added mercurial and the forest
>> extensions. But while the forest extensions work flawlessly (I could
>> download da Vinci), the mq extensions do not, although they should come
>> preinstalled. And yes, the flags are configured in the .hgrc file
>> according to the build instructions of the mlvm (I tried both mq= and
>> hgext.mq=).
>>
>> Did you (or anybody watching) encounter similar problems with
>> mercurial/OpenSolaris.2009-06?
> 
> No, never had problems with it.  Do you have the mq.py file?
> 
> twisti at macbook:~$ grep mq .hgrc
> mq =
> twisti at macbook:~$ ls -l /usr/lib/python2.4/vendor-packages/hgext/mq.py
> -r--r--r-- 1 root bin 97773 2009-07-23 19:58 /usr/lib/python2.4/vendor-packages/hgext/mq.py
> 

Yes, all mercurial py modules are there, installed by invoking
pkg install SUNWmercurial. None of them, however, is accessed by hg. I
suspect the installer fails to setup something in the environment to
make python aware of the vendor-packages folder.





From Christian.Thalinger at Sun.COM  Thu Oct 22 02:03:26 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Thu, 22 Oct 2009 11:03:26 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <4AE01E38.1040303@gmail.com>
References: <4ADDCFD5.50703@gmail.com> <1256051010.820.103.camel@macbook>
	<4ADF3227.4050608@gmail.com> <1256148286.21356.31.camel@macbook>
	<4AE01E38.1040303@gmail.com>
Message-ID: <1256202207.833.6.camel@macbook>

On Thu, 2009-10-22 at 10:56 +0200, Raffaello Giulietti wrote:
> Yes, all mercurial py modules are there, installed by invoking
> pkg install SUNWmercurial. None of them, however, is accessed by hg. I
> suspect the installer fails to setup something in the environment to
> make python aware of the vendor-packages folder.

Sorry, I don't know.  I only installed the SUNWmercurial package and it
worked.  Something strange in your .hgrc?

-- Christian


From raffaello.giulietti at gmail.com  Thu Oct 22 02:18:19 2009
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 22 Oct 2009 11:18:19 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <1256202207.833.6.camel@macbook>
References: <4ADDCFD5.50703@gmail.com>
	<1256051010.820.103.camel@macbook>	<4ADF3227.4050608@gmail.com>
	<1256148286.21356.31.camel@macbook>	<4AE01E38.1040303@gmail.com>
	<1256202207.833.6.camel@macbook>
Message-ID: <4AE0235B.3080005@gmail.com>

Christian Thalinger wrote:
> On Thu, 2009-10-22 at 10:56 +0200, Raffaello Giulietti wrote:
>> Yes, all mercurial py modules are there, installed by invoking
>> pkg install SUNWmercurial. None of them, however, is accessed by hg. I
>> suspect the installer fails to setup something in the environment to
>> make python aware of the vendor-packages folder.
> 
> Sorry, I don't know.  I only installed the SUNWmercurial package and it
> worked.  Something strange in your .hgrc?
> 

Christian, my .hgrc is exactly as recommended by the mlvm doc.

I'll ask some knowledgeable python guy about how to configure it to
access the vendor-packages dir.

Thanks so much
Raffaello

From Christian.Thalinger at Sun.COM  Thu Oct 22 02:20:56 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Thu, 22 Oct 2009 09:20:56 +0000
Subject: hg: mlvm/mlvm/hotspot: indy-amd64: Review changes.
Message-ID: <20091022092056.77C4D41526@hg.openjdk.java.net>

Changeset: b10789e6d957
Author:    twisti
Date:      2009-10-22 10:55 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b10789e6d957

indy-amd64: Review changes.

! indy-amd64.patch


From Christian.Thalinger at Sun.COM  Thu Oct 22 02:23:05 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Thu, 22 Oct 2009 11:23:05 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <4AE0235B.3080005@gmail.com>
References: <4ADDCFD5.50703@gmail.com> <1256051010.820.103.camel@macbook>
	<4ADF3227.4050608@gmail.com> <1256148286.21356.31.camel@macbook>
	<4AE01E38.1040303@gmail.com> <1256202207.833.6.camel@macbook>
	<4AE0235B.3080005@gmail.com>
Message-ID: <1256203385.833.8.camel@macbook>

On Thu, 2009-10-22 at 11:18 +0200, Raffaello Giulietti wrote:
> Christian Thalinger wrote:
> > On Thu, 2009-10-22 at 10:56 +0200, Raffaello Giulietti wrote:
> >> Yes, all mercurial py modules are there, installed by invoking
> >> pkg install SUNWmercurial. None of them, however, is accessed by hg. I
> >> suspect the installer fails to setup something in the environment to
> >> make python aware of the vendor-packages folder.
> > 
> > Sorry, I don't know.  I only installed the SUNWmercurial package and it
> > worked.  Something strange in your .hgrc?
> > 
> 
> Christian, my .hgrc is exactly as recommended by the mlvm doc.
> 
> I'll ask some knowledgeable python guy about how to configure it to
> access the vendor-packages dir.

Btw. did you try to specify the mq.py file, like I do for the forest
extension:

forest = ~/.hgext/hgforest/forest.py

-- Christian


From Christian.Thalinger at Sun.COM  Thu Oct 22 02:33:53 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Thu, 22 Oct 2009 09:33:53 +0000
Subject: hg: mlvm/mlvm/hotspot: series: Make dynopt.patch -buildable for now.
Message-ID: <20091022093353.900104152A@hg.openjdk.java.net>

Changeset: 64568693be14
Author:    twisti
Date:      2009-10-22 11:33 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/64568693be14

series: Make dynopt.patch -buildable for now.

! series


From raffaello.giulietti at gmail.com  Thu Oct 22 02:53:26 2009
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 22 Oct 2009 11:53:26 +0200
Subject: good platform to build da Vinci on?
In-Reply-To: <1256203385.833.8.camel@macbook>
References: <4ADDCFD5.50703@gmail.com>
	<1256051010.820.103.camel@macbook>	<4ADF3227.4050608@gmail.com>
	<1256148286.21356.31.camel@macbook>	<4AE01E38.1040303@gmail.com>
	<1256202207.833.6.camel@macbook>	<4AE0235B.3080005@gmail.com>
	<1256203385.833.8.camel@macbook>
Message-ID: <4AE02B96.2090606@gmail.com>

Christian Thalinger wrote:
> On Thu, 2009-10-22 at 11:18 +0200, Raffaello Giulietti wrote:
>> Christian Thalinger wrote:
>>> On Thu, 2009-10-22 at 10:56 +0200, Raffaello Giulietti wrote:
>>>> Yes, all mercurial py modules are there, installed by invoking
>>>> pkg install SUNWmercurial. None of them, however, is accessed by hg. I
>>>> suspect the installer fails to setup something in the environment to
>>>> make python aware of the vendor-packages folder.
>>> Sorry, I don't know.  I only installed the SUNWmercurial package and it
>>> worked.  Something strange in your .hgrc?
>>>
>> Christian, my .hgrc is exactly as recommended by the mlvm doc.
>>
>> I'll ask some knowledgeable python guy about how to configure it to
>> access the vendor-packages dir.
> 
> Btw. did you try to specify the mq.py file, like I do for the forest
> extension:
> 
> forest = ~/.hgext/hgforest/forest.py
> 

No, what I finally did was to make the path to mq.py explicit in .hgrc

[extensions]
mq=/usr/lib/python2.4/vendor-packages/hgext/mq.py


Thanks, Christian

From Christian.Thalinger at Sun.COM  Fri Oct 23 05:27:14 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Fri, 23 Oct 2009 14:27:14 +0200
Subject: hg: mlvm/mlvm/hotspot: dynopt: Updated to jdk7-b74.
In-Reply-To: <1256131339.21356.1.camel@macbook>
References: <20091021130701.A2B2F4140A@hg.openjdk.java.net>
	<1256131339.21356.1.camel@macbook>
Message-ID: <1256300835.833.29.camel@macbook>

On Wed, 2009-10-21 at 15:22 +0200, Christian Thalinger wrote:
> On Wed, 2009-10-21 at 13:07 +0000, Christian.Thalinger at Sun.COM wrote:
> > Changeset: 1fadccb2002c
> > Author:    twisti
> > Date:      2009-10-21 15:05 +0200
> > URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1fadccb2002c
> > 
> > dynopt: Updated to jdk7-b74.
> > indy-6858164: Fixed typo.
> > 
> > ! dynopt.patch
> 
> dynopt.patch is still broken.  Please don't apply it!

FYI, I have disabled that patch for now.  -- Christian


From Christian.Thalinger at Sun.COM  Tue Oct 27 08:04:15 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Tue, 27 Oct 2009 15:04:15 +0000
Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Changed oops to handles
	to be GC safe.
Message-ID: <20091027150416.5071541D6D@hg.openjdk.java.net>

Changeset: 5972cb463866
Author:    twisti
Date:      2009-10-27 16:03 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5972cb463866

indy.compiler.inline: Changed oops to handles to be GC safe.

! indy.compiler.inline.patch


From Christian.Thalinger at Sun.COM  Wed Oct 28 10:19:50 2009
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Wed, 28 Oct 2009 17:19:50 +0000
Subject: hg: mlvm/mlvm/hotspot: indy-cleanup-6893081: Fixed a bug with
	describe_scope and reverted usage of get_c2i_entry().
Message-ID: <20091028171951.28E1C415E3@hg.openjdk.java.net>

Changeset: c9d548e790a6
Author:    twisti
Date:      2009-10-28 18:19 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c9d548e790a6

indy-cleanup-6893081: Fixed a bug with describe_scope and reverted usage of get_c2i_entry().
indy.compiler.patch: Updated to apply cleanly on previous patch.

! indy-cleanup-6893081.patch
! indy.compiler.patch


From forax at univ-mlv.fr  Sat Oct 31 08:37:48 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 31 Oct 2009 16:37:48 +0100
Subject: mlvm don't build
Message-ID: <4AEC59CC.9010605@univ-mlv.fr>

No way to apply the patch series as is.

+ (cd sources/hotspot; hg qpush -a)
applying snowleopard.patch
applying meth-6815692.patch
applying indy-6858164.patch
applying indy-amd64.patch
applying meth.walker.patch
applying indy-cleanup-6893081.patch
applying indy.compiler.patch
skipping indy.compiler.inline.patch - guarded by '-testable'
skipping dynopt.patch - guarded by '-buildable'
skipping indy-sparc.patch - guarded by '-buildable'
skipping meth.proj.patch - guarded by ['+projects']
skipping anonk.proj.patch - guarded by ['+projects']
skipping annot.patch - guarded by '-testable'
skipping inti.patch - guarded by '-buildable'
skipping callcc.patch - guarded by '-testable'
skipping tailc.patch - guarded by ['+tailc-lazy']
skipping tailc-eager.patch - guarded by ['+tailc-lazy']
skipping hotswap.patch - guarded by ['+hotswap']
now at: indy.compiler.patch
+ (cd sources/jdk; hg qpush -a)
applying regtest-6891770.patch
applying indy.tests.patch
patching file test/java/dyn/MethodHandlesTest.java
Hunk #2 FAILED at 110
1 out of 16 hunks FAILED -- saving rejects to file 
test/java/dyn/MethodHandlesTest.java.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh indy.tests.patch
*** Exit status 2.
+ (cd sources/langtools; hg qpush -a)
applying meth.patch
skipping dyncast.patch - guarded by ['+dyncast']
skipping tailc.patch - guarded by ['+tailc']
now at: meth.patch

indy.tests.patch seems to be the offending patch.

R?mi

From forax at univ-mlv.fr  Sat Oct 31 13:00:47 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 31 Oct 2009 21:00:47 +0100
Subject: Patch, patch or patch
Message-ID: <4AEC976F.3030600@univ-mlv.fr>

Ignoring the patch that test indy,
I've managed to have a build that compile.

But it doesn't work,
jdk/ MethodHandleNatives.java is not in sync with
hotspot/ methodHandles.cpp

So at runtime, the VM warning me :)
OpenJDK Server VM warning: JSR 292 method handle code is mismatched to 
this JVM.  Disabling support.
OpenJDK Server VM warning: JSR 292 method handle code is mismatched to 
this JVM.  Disabling support.

As far as I can see linkCallSite in hotspot takes a CallSite and a 
MethodHandle
(there is also a weird space between them).

#define CST   JDYN"CallSite;"
#define MH    JDYN"MethodHandle;"
// More entry points specifically for EnableInvokeDynamic.
static JNINativeMethod methods2[] = {
   {CC"linkCallSite",            CC"("CST MH")V",                
FN_PTR(MH_linkCallSite)}
};

And on Java side, the native method is declared as this:

/** Tell the JVM that we need to change the target of an invokedynamic. */
     static native void linkCallSite(CallSiteImpl site, MethodHandle 
target);

So the VM try to find a linkcallSite(CallSite, MethodHandle) and
the java code declare a linkCallSite(CallSiteImpl, MethodHandle)

Oups, mismatch,
I hope I've not forgotten to apply a patch.

R?mi