From thobes at gmail.com  Fri Jan  2 07:59:28 2009
From: thobes at gmail.com (Tobias Ivarsson)
Date: Fri, 2 Jan 2009 16:59:28 +0100
Subject: hg.openjdk.java.net down?
Message-ID: <9997d5e60901020759n45d8971t40a0026d9805f5ca@mail.gmail.com>

Hi,

I keep getting "500 - Internal Server Error" from hg.openjdk.java.net. Does
anyone here know who to contact about this issue? And if it's not going to
be fixed soon, does anyone have an up to date clone that I can use?

Thanks
/Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090102/379d93b6/attachment.html 

From forax at univ-mlv.fr  Sat Jan  3 04:45:38 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 03 Jan 2009 13:45:38 +0100
Subject: hg.openjdk.java.net down?
In-Reply-To: <9997d5e60901020759n45d8971t40a0026d9805f5ca@mail.gmail.com>
References: <9997d5e60901020759n45d8971t40a0026d9805f5ca@mail.gmail.com>
Message-ID: <495F5DF2.70409@univ-mlv.fr>

Tobias Ivarsson a ?crit :
> Hi,
>
> I keep getting "500 - Internal Server Error" from hg.openjdk.java.net 
> <http://hg.openjdk.java.net>. Does anyone here know who to contact 
> about this issue? 
webmaster at openjdk.java.net
> And if it's not going to be fixed soon, does anyone have an up to date 
> clone that I can use?
Seems to be fixed, now.
>
> Thanks
> /Tobias
R?mi


From thobes at gmail.com  Sat Jan  3 05:56:35 2009
From: thobes at gmail.com (Tobias Ivarsson)
Date: Sat, 3 Jan 2009 14:56:35 +0100
Subject: hg.openjdk.java.net down?
In-Reply-To: <495F5DF2.70409@univ-mlv.fr>
References: <9997d5e60901020759n45d8971t40a0026d9805f5ca@mail.gmail.com>
	<495F5DF2.70409@univ-mlv.fr>
Message-ID: <9997d5e60901030556t5066ec98m90499a13deae88fe@mail.gmail.com>

On Sat, Jan 3, 2009 at 1:45 PM, R?mi Forax <forax at univ-mlv.fr> wrote:

> Tobias Ivarsson a ?crit :
> > Hi,
> >
> > I keep getting "500 - Internal Server Error" from hg.openjdk.java.net
> > <http://hg.openjdk.java.net>. Does anyone here know who to contact
> > about this issue?
> webmaster at openjdk.java.net
> > And if it's not going to be fixed soon, does anyone have an up to date
> > clone that I can use?
> Seems to be fixed, now.


You're right. Excellent! Now I can retarget my patches and continue working.


>
> >
> > Thanks
> > /Tobias
> R?mi
> _______________________________________________
> 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/20090103/e83221f7/attachment.html 

From john.rose at sun.com  Mon Jan 19 23:56:04 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 20 Jan 2009 07:56:04 +0000
Subject: hg: mlvm/mlvm/hotspot: meth: Happy New Year;
	better JVM code, more adapters, some unit tests
Message-ID: <20090120075605.25D50DBE7@hg.openjdk.java.net>

Changeset: 0eebfd40132b
Author:    jrose
Date:      2009-01-19 23:50 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0eebfd40132b

meth: Happy New Year; better JVM code, more adapters, some unit tests

! anonk.proj.patch
! meth.patch
! meth.proj.patch
! meth.txt



From John.Rose at Sun.COM  Tue Jan 20 00:48:30 2009
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 20 Jan 2009 00:48:30 -0800
Subject: happy new year!
Message-ID: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>

As you may have noticed, I just pushed a new patch set for method  
handles.  This closes off a coding sprint (or hike or ramble?) that  
began in early December.  The main visible results are a more mature  
javadoc API (draft--draft--draft!) and a bunch of unit tests.  The  
unit tests, even though they are limited, provide the best "cookbook"  
so far for using method handles.

Under the hood, the code has been made more modular, and I have tried  
to move work from JVM C++ code to trusted Java code (the shape of the  
future).  There is a complete set of non-blocking machine-level  
adapters.

(A non-blocking adapter is one which does not need to run Java code  
and has no allocation points.  Unboxing is non-blocking, while boxing  
can block and must therefore be done in a Java-based adapter.)

Missing bits include Java-based adapters, optimizer support (i.e.,  
code-generation of MH's which are compile-time constants) and  
integration of proposed Java language changes for invokedynamic and  
direct method handle invocation.  The unit tests use a clunky  
"invoker" class which requires the arguments to be boxed and varargs- 
ed, which is what method handles and invokedynamic are supposed to  
help us avoid.

As I see it, here's what needs to happen soon on the mlvm project.

1. finish the next draft of the invokedynamic spec. for the JSR 292  
EG to consider (this is roughly coordinated with the implementation  
work)
2. get a code review cycle done so we can move more of the JSR 292 RI  
into the JDK 7 workspace
3. update indy.patch to follow meth.patch
4. figuring out how to integrate a modified javac (w/ JSR 292  
support) into NetBeans, so we can write test case code with native  
syntax for method handles and invokedynamic
5. encourage the great work that people are doing or will do on tail  
call, continuations, interface injection, invokedynamic, etc.  
(Cheers, Arnold, Lukas, Tobias, Remi.)
6. assist Sun's test engineers as they begin building a real test suite
7. add JIT support, especially for inlining method handles at  
invokedynamic sites
8. work with brave language implementors (hi, Charlie, Brian) who  
want to try this stuff out sooner rather than later

Best wishes for a Multi-Lingual New Year!

-- John

P.S.  Re #4, if you know any netbeans hackers out there who want to  
help the JVM support new languages, you might let them know about  
these tiny language changes we will be proposing:
   http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.txt
   http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/quid.txt



From pdoubleya at gmail.com  Tue Jan 20 01:50:46 2009
From: pdoubleya at gmail.com (Patrick Wright)
Date: Tue, 20 Jan 2009 10:50:46 +0100
Subject: happy new year!
In-Reply-To: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
Message-ID: <64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>

John

Thanks for the update.

> 5. encourage the great work that people are doing or will do on tail
> call, continuations, interface injection, invokedynamic, etc.
> (Cheers, Arnold, Lukas, Tobias, Remi.)

It would be great to get an update on how these sub-projects are
going, what they are (currently, realistically) aiming to achieve,
etc. Perhaps the people involved can give us a brief status update?


Thanks!
Patrick


From forax at univ-mlv.fr  Tue Jan 20 02:28:21 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 20 Jan 2009 11:28:21 +0100
Subject: happy new year!
In-Reply-To: <64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
Message-ID: <4975A745.4070301@univ-mlv.fr>

Patrick Wright a ?crit :
> John
>
> Thanks for the update.
>
>   
>> 5. encourage the great work that people are doing or will do on tail
>> call, continuations, interface injection, invokedynamic, etc.
>> (Cheers, Arnold, Lukas, Tobias, Remi.)
>>     
>
> It would be great to get an update on how these sub-projects are
> going, what they are (currently, realistically) aiming to achieve,
> etc. Perhaps the people involved can give us a brief status update?
>   
R?mi = invokedynamic backport
be able to use method handle and invokedynamic on 1.5 VM
current status: in limbo :)
more precisely, the project work by detecting invokedynamic call or
method handle calls and translate them to an equivalent sequence
of bytecodes.
I use ASM to find and patch.
So currently there is a special branch of ASM named invokedynamic
that is able to read and write invokedynamic calls using the lastest
invokedynamic format (the one without receiver, i.e the one of the 
upcoming spec).

MethodHandle supports was almost ready before John changes the format of 
MethodType
(to add varargs bits). I haven't updated the corresponding ASM templates 
yet.
Invokedynamic supports need to be totally re-designed because it is 
based on the
assertion that the method bootstrap on an invokedynamic call is available
during the loading of the bytecode. This assertion seems to be false.
That's the risk of life on bleeding edge :)

I will able to fully update the backport during my next vacation,
in the end of february.
>
> Thanks!
> Patrick
>   
Regards,
R?mi


From forax at univ-mlv.fr  Tue Jan 20 02:32:27 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 20 Jan 2009 11:32:27 +0100
Subject: happy new year!
In-Reply-To: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
Message-ID: <4975A83B.9050706@univ-mlv.fr>

John Rose a ?crit :
> As you may have noticed, I just pushed a new patch set for method  
> handles.  This closes off a coding sprint (or hike or ramble?) that  
> began in early December.  The main visible results are a more mature  
> javadoc API (draft--draft--draft!) and a bunch of unit tests.  The  
> unit tests, even though they are limited, provide the best "cookbook"  
> so far for using method handles.
>   
Hi john,
the meth patch doesn't seem to work.
Is this patch against the rev jdk7-b42 of the jdk7 workspace ?
> Under the hood, the code has been made more modular, and I have tried  
> to move work from JVM C++ code to trusted Java code (the shape of the  
> future).  There is a complete set of non-blocking machine-level  
> adapters.
>
> (A non-blocking adapter is one which does not need to run Java code  
> and has no allocation points.  Unboxing is non-blocking, while boxing  
> can block and must therefore be done in a Java-based adapter.)
>
> Missing bits include Java-based adapters, optimizer support (i.e.,  
> code-generation of MH's which are compile-time constants) and  
> integration of proposed Java language changes for invokedynamic and  
> direct method handle invocation.  The unit tests use a clunky  
> "invoker" class which requires the arguments to be boxed and varargs- 
> ed, which is what method handles and invokedynamic are supposed to  
> help us avoid.
>
> As I see it, here's what needs to happen soon on the mlvm project.
>
> 1. finish the next draft of the invokedynamic spec. for the JSR 292  
> EG to consider (this is roughly coordinated with the implementation  
> work)
> 2. get a code review cycle done so we can move more of the JSR 292 RI  
> into the JDK 7 workspace
> 3. update indy.patch to follow meth.patch
> 4. figuring out how to integrate a modified javac (w/ JSR 292  
> support) into NetBeans, so we can write test case code with native  
> syntax for method handles and invokedynamic
> 5. encourage the great work that people are doing or will do on tail  
> call, continuations, interface injection, invokedynamic, etc.  
> (Cheers, Arnold, Lukas, Tobias, Remi.)
> 6. assist Sun's test engineers as they begin building a real test suite
> 7. add JIT support, especially for inlining method handles at  
> invokedynamic sites
> 8. work with brave language implementors (hi, Charlie, Brian) who  
> want to try this stuff out sooner rather than later
>
> Best wishes for a Multi-Lingual New Year!
>
> -- John
>
> P.S.  Re #4, if you know any netbeans hackers out there who want to  
> help the JVM support new languages, you might let them know about  
> these tiny language changes we will be proposing:
>    http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.txt
>    http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/quid.txt
>   
R?mi


From John.Rose at Sun.COM  Tue Jan 20 02:39:32 2009
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 20 Jan 2009 02:39:32 -0800
Subject: happy new year!
In-Reply-To: <4975A745.4070301@univ-mlv.fr>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
	<4975A745.4070301@univ-mlv.fr>
Message-ID: <C82AFB72-7CAB-47D0-AA90-065AF746ABAB@sun.com>

On Jan 20, 2009, at 2:28 AM, R?mi Forax wrote:

> MethodHandle supports was almost ready before John changes the  
> format of
> MethodType
> (to add varargs bits)

Aghh!  Stub out the varargs bits if you want; after using them a  
little I'm beginning to think they are not worth the trouble.  Sorry  
for the thrash.

The key insight, I think, is that method handles are pure JVM-level  
behavior, without attached intentions like "I have an optional  
argument" or "I am a field setter"; that sort of information properly  
belongs in the (mangled) invocation name of invokedynamic, not wedged  
into the method handle or its type.  The varargs bit in MethodType,  
although temptingly connected to the varargs bit in JVM methods,  
doesn't really help things fit together.  In particular, there is no  
way (that I can see) to issue a true varargs call from bytecode.   
Given the following invokevirtual, where does the varargs part appear?

    invokevirtual java/dyn/MethodHandle, invoke, ([Ljava/lang/Object;)V

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090120/641c090b/attachment.html 

From John.Rose at Sun.COM  Tue Jan 20 02:42:25 2009
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 20 Jan 2009 02:42:25 -0800
Subject: happy new year!
In-Reply-To: <4975A83B.9050706@univ-mlv.fr>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<4975A83B.9050706@univ-mlv.fr>
Message-ID: <8EAC5EE2-24AB-4EA9-AF36-7852F3E51467@sun.com>

On Jan 20, 2009, at 2:32 AM, R?mi Forax wrote:

> the meth patch doesn't seem to work.
> Is this patch against the rev jdk7-b42 of the jdk7 workspace ?

Actually, it's against f6c0827e5919 which is the current contents of  
http://hg.openjdk.java.net/jdk7/hotspot/hotspot .

I suppose I need to put the exact URL of the base revision into the  
patch (somewhere prominent).  The guard hack doesn't seem to buy  
much.  I'm open to suggestions; what would make your life easier??

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

From thobes at gmail.com  Tue Jan 20 02:59:41 2009
From: thobes at gmail.com (Tobias Ivarsson)
Date: Tue, 20 Jan 2009 11:59:41 +0100
Subject: happy new year!
In-Reply-To: <64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
Message-ID: <9997d5e60901200259u7904a444y45048fb4ce4e16b8@mail.gmail.com>

On Tue, Jan 20, 2009 at 10:50 AM, Patrick Wright <pdoubleya at gmail.com>wrote:

> John
>
> Thanks for the update.
>
> > 5. encourage the great work that people are doing or will do on tail
> > call, continuations, interface injection, invokedynamic, etc.
> > (Cheers, Arnold, Lukas, Tobias, Remi.)
>
> It would be great to get an update on how these sub-projects are
> going, what they are (currently, realistically) aiming to achieve,
> etc. Perhaps the people involved can give us a brief status update?


Of course, that's an excellent suggestion. I (Tobias Ivarsson) spend my time
working on interface injection (inti.patch). The aims of which are to enable
the JVM to inject an interface, with implementing methods, into an already
loaded class that was not compiled as implementing that interface. The
original hope (that at least I had) for this was that you would be able to
inject any interface into any class. But I am starting to think that this
will impose too much complication in dealing with rejected interfaces, for
example if the JVM has checked if a class implements an interface before it
becomes injectable. My current idea is therefore that for an interface to be
injectable it has to be marked as such when loaded. I think this will have
minimal impact on usefulness of interface injection, but comments on this
issue are appreciated.

My plan, that I announced here on the list early December, was to work on
interface injection during the holidays. As things always are with the
holidays, I didn't get as much time for work as I had hoped. Most of the
work happened last week instead. And most of my time has been spent reading
code and drawing things on my whiteboard. I now feel that I have managed to
map out the design of most things on the C++ level. Many aspects will be
implemented in Java, but those are easier to change in a later iteration.

My next milestone is that I hope to run into problems by the end of this
week, or early next week, with not having easy access to a SPARC machine or
any machine where I can install Solaris for testing the implementation in
that build environment. At this point I plan to share inti.patch with you
guys and get some feedback.

Cheers,
Tobias Ivarsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090120/26ba6e10/attachment.html 

From John.Rose at Sun.COM  Tue Jan 20 03:13:19 2009
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 20 Jan 2009 03:13:19 -0800
Subject: happy new year!
In-Reply-To: <9997d5e60901200259u7904a444y45048fb4ce4e16b8@mail.gmail.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
	<9997d5e60901200259u7904a444y45048fb4ce4e16b8@mail.gmail.com>
Message-ID: <E448C911-B951-4F98-9007-CBD6CE0CEE8A@sun.com>

On Jan 20, 2009, at 2:59 AM, Tobias Ivarsson wrote:

> I now feel that I have managed to map out the design of most things  
> on the C++ level. Many aspects will be implemented in Java, but  
> those are easier to change in a later iteration.

Excellent!

As part of the method handle work, I've refactored the interface  
dispatch code into MacroAssembler::lookup_interface_method.
(It used to be in two places; now it will be in a single place and  
ready to be extended.)  Please check out this webrev:
   http://webrev.invokedynamic.info/jrose/6655638.meth/src/cpu/x86/vm/ 
assembler_x86.cpp.udiff.html

This change is under review now, and will be pushed (I expect) into  
the JDK7 baseline in a few weeks.

> My next milestone is that I hope to run into problems by the end of  
> this week, or early next week, with not having easy access to a  
> SPARC machine or any machine where I can install Solaris for  
> testing the implementation in that build environment. At this point  
> I plan to share inti.patch with you guys and get some feedback.

I run all my development builds on x86 Solaris, using VMWare on  
MacBook.  (VirtualBox doesn't support 64-bit yet, but I'm watching  
for it.)  It's all publicly available...  See http://wikis.sun.com/ 
display/SunOnMac/Home for some older hints.  SPARC is where a lot of  
the big applications will be running, but for development x86 is great.

Best wishes,
-- John


From Dalibor.Topic at Sun.COM  Tue Jan 20 03:30:11 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Tue, 20 Jan 2009 12:30:11 +0100
Subject: happy new year!
In-Reply-To: <E448C911-B951-4F98-9007-CBD6CE0CEE8A@sun.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
	<9997d5e60901200259u7904a444y45048fb4ce4e16b8@mail.gmail.com>
	<E448C911-B951-4F98-9007-CBD6CE0CEE8A@sun.com>
Message-ID: <4975B5C3.1090501@Sun.COM>

On 20.01.09 12:13, John Rose wrote:
> I run all my development builds on x86 Solaris, using VMWare on  
> MacBook.  (VirtualBox doesn't support 64-bit yet, but I'm watching  
> for it.)
Experimental support for 64 bit guests on 32 bit systems has been added in
Virtualbox 2.1.0. I haven't tried that myself on a Mac yet, though.

cheers,
dalibor topic

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer
Vorsitzender des Aufsichtsrates: Martin H?ring



From john.rose at sun.com  Tue Jan 20 23:13:25 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 21 Jan 2009 07:13:25 +0000
Subject: hg: mlvm/mlvm/langtools: 2 new changesets
Message-ID: <20090121071325.C1E0BDCCB@hg.openjdk.java.net>

Changeset: 6de49f01c9f0
Author:    jrose
Date:      2009-01-20 23:10 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/6de49f01c9f0

temporary patch from Jon Gibbons for NetBeans 6.5

+ gibbons.patch
+ gibbons.txt
! series

Changeset: 767977c02b54
Author:    jrose
Date:      2009-01-20 23:11 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/767977c02b54

meth: remove all but one form of invokedynamic; document NetBeans based development

! meth.patch
! meth.txt



From arnold.schwaighofer at gmail.com  Wed Jan 21 03:46:09 2009
From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer)
Date: Wed, 21 Jan 2009 12:46:09 +0100
Subject: happy new year!
In-Reply-To: <64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
Message-ID: <b8c6f2610901210346o6d0686ebkd1f2d85d2313f6ae@mail.gmail.com>

Hi everybody,

i am working on the project to bring tail calls to Hotspot.

A prototype was implemented on x86-32 and will hopefully be soon
availabe on the mlvm site.
The modified hotspot supports tail calls in the interpreter, client
and server compiler.
To mark a call as tail call the programmer emits a 'wide' byte code
before the various invoke... instructions.
The verifier checks that the call really is a tail call (i.e the last
thing the method does before it returns etc.).
Hotspot guarantees that a series of such tail calls execute in bounded
stack space. That is no stackoverflow exception happens.
The vm implements most tail calls by removing the calling stack frame.
Some stack frames can not be removed because of java's access security
mechanism. Every stack frame points to a protection domain via which
permissions can be computed. On access to a guarded resource
permissions are computed by intersecting all protection domains that
are on the stack. If caller and callee protection domain are different
we can not remove the caller's stack frame (or we would have to look
whether an ancestor frame already has the same pd on every call - not
very efficient). In such a case the tail call proceeds like a normal
function call i.e leaving a stack frame. If a series of tail calls
with different pds happen the stack grows. Eventually if the recursion
is deep enough a stack overflow would happen. The implementation
catches this situation and compresses the stack by removing stack
frames that have the same protection domain.

The prototype is mostly finished. I am currently writing my thesis
describing the changes and hope to be finished mid february. By then i
hope to have cleaned up the code and will probably post it here on the
mail list.

regards arnold

On Tue, Jan 20, 2009 at 10:50 AM, Patrick Wright <pdoubleya at gmail.com> wrote:
> John
>
> Thanks for the update.
>
>> 5. encourage the great work that people are doing or will do on tail
>> call, continuations, interface injection, invokedynamic, etc.
>> (Cheers, Arnold, Lukas, Tobias, Remi.)
>
> It would be great to get an update on how these sub-projects are
> going, what they are (currently, realistically) aiming to achieve,
> etc. Perhaps the people involved can give us a brief status update?
>
>
> Thanks!
> Patrick
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From blackdrag at gmx.org  Wed Jan 21 06:33:16 2009
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Wed, 21 Jan 2009 15:33:16 +0100
Subject: happy new year!
In-Reply-To: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
Message-ID: <4977322C.8060501@gmx.org>

John Rose schrieb:
[...]
> 8. work with brave language implementors (hi, Charlie, Brian) who  
> want to try this stuff out sooner rather than later

since Groovy 1.6 seems to finally setlle down I would have time to 
actually produce a Groovy version that uses the method handles and 
invokedynamic stuff. But for this I need a patch that actually compiles 
on my system. I had problems with the earlier beta version, but b42 
seems to compile fine.

The more language adopt it early the more optimization into different 
directions can be done. And maybe one or two limitations will surface.

For this I don't need a modified javac since the asm lib seems to 
support invokedynamic.

bye Jochen
-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/



From lukas.stadler at jku.at  Wed Jan 21 08:38:56 2009
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Wed, 21 Jan 2009 17:38:56 +0100
Subject: happy new year!
In-Reply-To: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
Message-ID: <49774FA0.4070405@jku.at>

Hi!

I'm working on the continuations part...
I have recently started a new approach to the continuations copy and 
resume implementation. I was never all that happy with using the 
debugging structures to extract the information from the stack frames. 
So I've now developed an algorithm that stores stack frames on-demand by 
patching the return addresses on stack. This has some very exciting 
advantages, e.g. the stack frames that haven't been modified yet will 
never be copied or restored (because all the information that the 
continuation needs from the stack frame is still present on the stack).

By now I've completed the copy part (which is very useful on its own :-) 
and am now working on the restore part. There are still some problems to 
solve, but we'll get there...
I'm also preparing a paper for this year's PPPJ conference, which will 
explain all this in great detail.

bye,
 Lukas



From charles.nutter at sun.com  Wed Jan 21 09:04:55 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Wed, 21 Jan 2009 11:04:55 -0600
Subject: happy new year!
In-Reply-To: <b8c6f2610901210346o6d0686ebkd1f2d85d2313f6ae@mail.gmail.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
	<b8c6f2610901210346o6d0686ebkd1f2d85d2313f6ae@mail.gmail.com>
Message-ID: <497755B7.6010902@sun.com>

Arnold Schwaighofer wrote:
> The prototype is mostly finished. I am currently writing my thesis
> describing the changes and hope to be finished mid february. By then i
> hope to have cleaned up the code and will probably post it here on the
> mail list.

Wow, that's really awesome. I knew work was going on but had no idea of 
progress. It looks like we may get all our toys into Java 7 after all!

- Charlie


From glaforge at gmail.com  Wed Jan 21 09:32:32 2009
From: glaforge at gmail.com (Guillaume Laforge)
Date: Wed, 21 Jan 2009 18:32:32 +0100
Subject: happy new year!
In-Reply-To: <497755B7.6010902@sun.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<64efa1ba0901200150j670cafdgb1faaf033657d2a4@mail.gmail.com>
	<b8c6f2610901210346o6d0686ebkd1f2d85d2313f6ae@mail.gmail.com>
	<497755B7.6010902@sun.com>
Message-ID: <197b18fc0901210932m7438c7c5odb54a5edad771b8a@mail.gmail.com>

On Wed, Jan 21, 2009 at 6:04 PM, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> Arnold Schwaighofer wrote:
>> The prototype is mostly finished. I am currently writing my thesis
>> describing the changes and hope to be finished mid february. By then i
>> hope to have cleaned up the code and will probably post it here on the
>> mail list.
>
> Wow, that's really awesome. I knew work was going on but had no idea of
> progress. It looks like we may get all our toys into Java 7 after all!

We really live in interesting times, my friends :-)

-- 
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


From John.Rose at Sun.COM  Wed Jan 21 10:52:19 2009
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 21 Jan 2009 10:52:19 -0800
Subject: NetBeans support for proposed small language extensions
Message-ID: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>

The mlvm/langtools patch repository has support for some small Java  
extensions, which I am in the process of proposing to the Java  
language people.

I have wired the updated javac into the ant scripts that NetBeans  
uses, and can build invokedynamic call sites directly from Java code  
in the NetBeans editor.  This will be a preferred way to create call  
sites for metaobject protocol infrastructure and any parts of dynamic  
language runtimes written in Java.  (Dynamic languages will probably  
not compile via Java, but use ASM to generate invokedynamic calls  
directly.)  You'll see the tweaks for that on my next hotspot push.

Meanwhile, NetBeans still (very reasonably) reports the extensions as  
syntax or type errors.  I just filed a NetBeans RFE to get this  
fixed.  Now all we need is a NetBeans expert!  (Are *you* that  
expert? :-)

http://www.netbeans.org/issues/show_bug.cgi?id=157264

Best wishes,
-- John


From forax at univ-mlv.fr  Wed Jan 21 12:01:42 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 21 Jan 2009 21:01:42 +0100
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
Message-ID: <49777F26.9070601@univ-mlv.fr>

John Rose a ?crit :
> The mlvm/langtools patch repository has support for some small Java  
> extensions, which I am in the process of proposing to the Java  
> language people.
>
> I have wired the updated javac into the ant scripts that NetBeans  
> uses, and can build invokedynamic call sites directly from Java code  
> in the NetBeans editor.  This will be a preferred way to create call  
> sites for metaobject protocol infrastructure and any parts of dynamic  
> language runtimes written in Java.  (Dynamic languages will probably  
> not compile via Java, but use ASM to generate invokedynamic calls  
> directly.)  You'll see the tweaks for that on my next hotspot push.
>
> Meanwhile, NetBeans still (very reasonably) reports the extensions as  
> syntax or type errors.  I just filed a NetBeans RFE to get this  
> fixed.  Now all we need is a NetBeans expert!  (Are *you* that  
> expert? :-)
>
> http://www.netbeans.org/issues/show_bug.cgi?id=157264
>
> Best wishes,
> -- John
>   
John,
I am not a big fan of the exotic identifier proposal mostly because
i doesn't understand the need and because using '#' creates conflicts
with several closure proposal (BGGA and CICE) and my modest
property proposal.

Correct me if i'm wrong, you need exotic identifiers if you are
a language developer that want to implement a part of the
langage runtime in Java. But if you are a language developer,
you control the compiler of that language so you can lookup
for extra meta-data when you want to call a method, a field
or a class written in Java.
By example, these metadata can be implemented using annotations
with no problem.

cheers,
R?mi




From charles.nutter at sun.com  Wed Jan 21 12:28:55 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Wed, 21 Jan 2009 14:28:55 -0600
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <49777F26.9070601@univ-mlv.fr>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
	<49777F26.9070601@univ-mlv.fr>
Message-ID: <49778587.9090704@sun.com>

? wrote:
> John,
> I am not a big fan of the exotic identifier proposal mostly because
> i doesn't understand the need and because using '#' creates conflicts
> with several closure proposal (BGGA and CICE) and my modest
> property proposal.

Can you give examples? I haven't looked at BGGA but I didn't remember it 
using # anywhere. And an example of your proposal too?

> Correct me if i'm wrong, you need exotic identifiers if you are
> a language developer that want to implement a part of the
> langage runtime in Java. But if you are a language developer,
> you control the compiler of that language so you can lookup
> for extra meta-data when you want to call a method, a field
> or a class written in Java.
> By example, these metadata can be implemented using annotations
> with no problem.

I think the problem, however, is that not all language impls will only 
ever want to do invokedynamic from that language's code; we may also 
want to do it from Java for simplicity of implementation.

- Charlie


From forax at univ-mlv.fr  Wed Jan 21 13:14:36 2009
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Wed, 21 Jan 2009 22:14:36 +0100
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <49778587.9090704@sun.com>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>	<49777F26.9070601@univ-mlv.fr>
	<49778587.9090704@sun.com>
Message-ID: <4977903C.9030902@univ-mlv.fr>

Charles Oliver Nutter a ?crit :
> ? wrote:
>   
>> John,
>> I am not a big fan of the exotic identifier proposal mostly because
>> i doesn't understand the need and because using '#' creates conflicts
>> with several closure proposal (BGGA and CICE) and my modest
>> property proposal.
>>     
>
> Can you give examples? I haven't looked at BGGA but I didn't remember it 
> using # anywhere. 
# is used to reference method, it's an equivalent to MethodHandles.find*,
techinaclly it's not in the spec but already int the prototype 
implementation
see http://www.javac.info/PrototypeDifferences.html.

You can find more examples here:
http://tronicek.blogspot.com/2008/03/method-references-version-2008-03-17.html

> And an example of your proposal too?
>   

My property proposal is available here:
http://docs.google.com/View?docid=dfhbvdfw_1f7mzf2

# is used to get a reified object corresponding to a property.

>   
>> Correct me if i'm wrong, you need exotic identifiers if you are
>> a language developer that want to implement a part of the
>> langage runtime in Java. But if you are a language developer,
>> you control the compiler of that language so you can lookup
>> for extra meta-data when you want to call a method, a field
>> or a class written in Java.
>> By example, these metadata can be implemented using annotations
>> with no problem.
>>     
>
> I think the problem, however, is that not all language impls will only 
> ever want to do invokedynamic from that language's code; we may also 
> want to do it from Java for simplicity of implementation.
>   
I have no problem with the patch that allow javac to emit invokedynamic
bytecode. I am even a strong supporter of this patch.

I have more doubts with the patch that allow exotic identifiers.
> - Charlie
>   
R?mi


From charles.nutter at sun.com  Wed Jan 21 14:00:18 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Wed, 21 Jan 2009 16:00:18 -0600
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <4977903C.9030902@univ-mlv.fr>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
	<49777F26.9070601@univ-mlv.fr> <49778587.9090704@sun.com>
	<4977903C.9030902@univ-mlv.fr>
Message-ID: <49779AF2.6010904@sun.com>

R?mi Forax wrote:
> I have no problem with the patch that allow javac to emit invokedynamic
> bytecode. I am even a strong supporter of this patch.
> 
> I have more doubts with the patch that allow exotic identifiers.

I suppose this is where a standardization process comes in handy :)

I'm not sure there's a way to reconcile multiple proposed Java languages 
changes that all want to use #. We have precious few symbols on a 
standard keyboard. One criteria might be the likelihood of a proposal 
making it into Java 7; that would mean indy gets to use # for tooling 
purposes. But indy doesn't also include Java language changes, does it? 
So this would only be a third-party extension to javac, not standard in 
the language.

I personally like the # for dynamic dispatch quite a bit since multiple 
dynlangs use it to identify methods (Rubyists frequently refer to 
methods like String#to_s).

It does occur to me that these various uses may be basically the same. 
Perhaps # with an identifier and no () would be your property syntax or 
BGGA method reference syntax (perhaps eventually to be method handle 
syntax?) and # with an identifier and () would be invocation syntax?

- Charlie


From John.Rose at Sun.COM  Wed Jan 21 15:04:48 2009
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 21 Jan 2009 15:04:48 -0800
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <49779AF2.6010904@sun.com>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
	<49777F26.9070601@univ-mlv.fr> <49778587.9090704@sun.com>
	<4977903C.9030902@univ-mlv.fr> <49779AF2.6010904@sun.com>
Message-ID: <255947C3-9949-4835-B4B8-8D0C8BED08B2@sun.com>

On Jan 21, 2009, at 2:00 PM, Charles Oliver Nutter wrote:

> I'm not sure there's a way to reconcile multiple proposed Java  
> languages
> changes that all want to use #.

The exotic identifiers proposal does not conflict with any use of  
hash '#' (that I am aware of) as a separator or operator.  That's  
because an exotic identifier is introduced by the two character  
sequence hash-quote '#"'.  It interferes with other uses of hash '#'  
as much as it interferes with other uses of quote '"':  That is, not  
at all.

On Jan 21, 2009, at 12:01 PM, R?mi Forax wrote:
> I am not a big fan of the exotic identifier proposal mostly because
> i doesn't understand the need

As Charlie pointed out, along with the Dynamic.foo() syntax, exotic  
identifiers allow Java to make direct calls to other languages.   
E.g., Dynamic.#"setcar!"(aCons, aValue) as well as Dynamic.list(aValue).

A second point:  I know that annotations are the current state of the  
art for assigning non-Java names to definitions.  But I think exotic  
identifiers will provide, in many new cases, a smoother way to allow  
Java to define names which are directly usable from non-Java languages.

> and because using '#' creates conflicts
> with several closure proposal (BGGA and CICE) and my modest
> property proposal.

See above.  For example, a proposed expression Author#name could be  
harmlessly requoted as #"Author"##"name".  The example is  
intentionally bad style, but there is no ambiguity.  At worst, an  
operator "##" (is anybody suggesting one?) would be lexically  
ambiguous if immediately followed by a string literal; the solution  
(as with all such ambiguities) is to introduce a space to separate  
the intended tokens.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090121/64801b46/attachment.html 

From John.Rose at Sun.COM  Wed Jan 21 15:33:11 2009
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 21 Jan 2009 15:33:11 -0800
Subject: happy new year!
In-Reply-To: <4977322C.8060501@gmx.org>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<4977322C.8060501@gmx.org>
Message-ID: <B08B640B-EC45-4E78-B495-61CF83C5AF72@sun.com>

On Jan 21, 2009, at 6:33 AM, Jochen Theodorou wrote:

> John Rose schrieb:
> [...]
>> 8. work with brave language implementors (hi, Charlie, Brian) who
>> want to try this stuff out sooner rather than later
>
> since Groovy 1.6 seems to finally setlle down I would have time to
> actually produce a Groovy version that uses the method handles and
> invokedynamic stuff. But for this I need a patch that actually  
> compiles
> on my system. I had problems with the earlier beta version, but b42
> seems to compile fine.

I've started putting the Mercurial hashcode of the baseline revision  
in the series file (.hg/patches/series) of each patch repository.   
For people who attempt their own builds (that's all of us at present)  
that will make it easier to apply the patches cleanly, and to know  
that resulting bugs are real, not due to micro-version skew.

> The more language adopt it early the more optimization into different
> directions can be done. And maybe one or two limitations will surface.

I hope and expect so!

> For this I don't need a modified javac since the asm lib seems to
> support invokedynamic.

Right.

BTW, the next version of invokedynamic (as emitted by yesterday's  
mlvm/langtools push and coming RSN in mlvm/hotspot/indy.patch)  
completely omits references to java.dyn.Dynamic in the constant  
pool.  The CP index in the instruction is to a CONSTANT_NameAndType,  
so don't use a CONSTANT_[Interface]MethodRef.  The two extension  
bytes (last of five) are both required to be zero and reserved for  
future use.

I'm eager to see what Groovy can do with these new goodies.

BTW, what do you think are the chances of interfactoring Groovy's MOP  
with Attila's?  The JSR 292 adoption might be a good time to think  
about it.

-- John


From blackdrag at gmx.org  Wed Jan 21 20:36:58 2009
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Thu, 22 Jan 2009 05:36:58 +0100
Subject: happy new year!
In-Reply-To: <B08B640B-EC45-4E78-B495-61CF83C5AF72@sun.com>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>	<4977322C.8060501@gmx.org>
	<B08B640B-EC45-4E78-B495-61CF83C5AF72@sun.com>
Message-ID: <4977F7EA.7080801@gmx.org>

John Rose schrieb:
[...]
> I'm eager to see what Groovy can do with these new goodies.

I too

> BTW, what do you think are the chances of interfactoring Groovy's MOP  
> with Attila's?  The JSR 292 adoption might be a good time to think  
> about it.

Atilla's work looks very much how Groovy used to work in 1.0 till 1.5. 
The upcoming 1.6 is going away from a call oriented MOP to a request 
based MOP. That means we request a callable object and then execute the 
call itself directly from the call site.

theoretically this can be done with Atilla's MOP too, but we would have 
to use the get method to get something callable and then call it... only 
that we need to transport information like caller, callee, arguments and 
of course methodname. And I am not sure how that would be done.

Of course suppporting Atilla's MOP as an interface to Groovy's MOP is a 
different story, since we can write a bunch of adapter classes and be 
done withit. Of course the use is then "limited" to interlanguage calls

bye Jochen

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/



From charles.nutter at sun.com  Wed Jan 21 23:10:27 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Thu, 22 Jan 2009 01:10:27 -0600
Subject: happy new year!
In-Reply-To: <4977F7EA.7080801@gmx.org>
References: <5B212BCC-4AA9-4A18-A8BF-7354C76DCF8D@sun.com>
	<4977322C.8060501@gmx.org>
	<B08B640B-EC45-4E78-B495-61CF83C5AF72@sun.com>
	<4977F7EA.7080801@gmx.org>
Message-ID: <49781BE3.1080705@sun.com>

Jochen Theodorou wrote:
> Atilla's work looks very much how Groovy used to work in 1.0 till 1.5. 
> The upcoming 1.6 is going away from a call oriented MOP to a request 
> based MOP. That means we request a callable object and then execute the 
> call itself directly from the call site.

This is how JRuby has worked since 1.0, though we do have a small shim 
class between the call site and the callable object to handle lookup, 
caching, and method_missing logic. But other than that it works very 
well, and our dispatch performance is quite good.

> theoretically this can be done with Atilla's MOP too, but we would have 
> to use the get method to get something callable and then call it... only 
> that we need to transport information like caller, callee, arguments and 
> of course methodname. And I am not sure how that would be done.

Atilla's Dynalang project could easily be modified to support the 
"callable" mechanism, and indeed would need such a modification to 
support both JRuby's current dispatch logic and invokedynamic. I'm 
hoping to start contributing to Dynalang very soon.

> Of course suppporting Atilla's MOP as an interface to Groovy's MOP is a 
> different story, since we can write a bunch of adapter classes and be 
> done withit. Of course the use is then "limited" to interlanguage calls

This is a good initial goal, and we've started looking into doing this 
for JRuby as well.

- Charlie


From forax at univ-mlv.fr  Thu Jan 22 01:14:29 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 22 Jan 2009 10:14:29 +0100
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <255947C3-9949-4835-B4B8-8D0C8BED08B2@sun.com>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>	<49777F26.9070601@univ-mlv.fr>
	<49778587.9090704@sun.com>	<4977903C.9030902@univ-mlv.fr>
	<49779AF2.6010904@sun.com>
	<255947C3-9949-4835-B4B8-8D0C8BED08B2@sun.com>
Message-ID: <497838F5.80204@univ-mlv.fr>

John Rose a ?crit :
> On Jan 21, 2009, at 2:00 PM, Charles Oliver Nutter wrote:
>
>> I'm not sure there's a way to reconcile multiple proposed Java languages 
>>
>> changes that all want to use #.
>>
>
> The exotic identifiers proposal does not conflict with any use of hash 
> '#' (that I am aware of) as a separator or operator.  That's because 
> an exotic identifier is introduced by the two character sequence 
> hash-quote '#"'.  It interferes with other uses of hash '#' as much as 
> it interferes with other uses of quote '"':  That is, not at all.
ok, I understand, the symbol is #" and not #.
>
> On Jan 21, 2009, at 12:01 PM, R?mi Forax wrote:
>> I am not a big fan of the exotic identifier proposal mostly because
>> i doesn't understand the need
>
> As Charlie pointed out, along with the Dynamic.foo() syntax, exotic 
> identifiers allow Java to make direct calls to other languages.  E.g., 
> Dynamic.#"setcar!"(aCons, aValue) as well as Dynamic.list(aValue).
In that case, you don't need '#',  Dynamic."setcar!"(aCons, aValue)
is not ambiguous. It will work with all qualified access to field and 
method.
>
> A second point:  I know that annotations are the current state of the 
> art for assigning non-Java names to definitions.  But I think exotic 
> identifiers will provide, in many new cases, a smoother way to allow 
> Java to define names which are directly usable from non-Java languages.
>
>> and because using '#' creates conflicts
>> with several closure proposal (BGGA and CICE) and my modest
>> property proposal.
>
> See above.  For example, a proposed expression Author#name could be 
> harmlessly requoted as #"Author"##"name".  The example is 
> intentionally bad style, but there is no ambiguity.  At worst, an 
> operator "##" (is anybody suggesting one?) would be lexically 
> ambiguous if immediately followed by a string literal; the solution 
> (as with all such ambiguities) is to introduce a space to separate the 
> intended tokens.
I understand the need to call a method with an exotic identifier but not 
the need to introduce
a way to use exotic identifiers at any place in the Java language.
With your RFE,  @#"{}"({@#"@"()}) will be a valid annotation and not a 
swearword :)
>
> -- John
R?mi


From John.Rose at Sun.COM  Thu Jan 22 03:04:34 2009
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 22 Jan 2009 03:04:34 -0800
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <497838F5.80204@univ-mlv.fr>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
	<49777F26.9070601@univ-mlv.fr> <49778587.9090704@sun.com>
	<4977903C.9030902@univ-mlv.fr> <49779AF2.6010904@sun.com>
	<255947C3-9949-4835-B4B8-8D0C8BED08B2@sun.com>
	<497838F5.80204@univ-mlv.fr>
Message-ID: <63920F4D-A044-42CD-8B33-C0538BECB364@sun.com>

On Jan 22, 2009, at 1:14 AM, R?mi Forax wrote:

> In that case, you don't need '#',  Dynamic."setcar!"(aCons, aValue)
> is not ambiguous. It will work with all qualified access to field and
> method.

That's what we did in Groovy; it works well there.  Java needs to be  
a little more formal, I think, and make a clear distinction between  
string literals and identifiers.

Restricting XIDs to qualified names is, I think, an unnatural  
restriction:  It does not follow use cases exactly enough.  In  
particular, it does not cover the use case I mentioned earlier, of  
defining exotic names (class/method/field) in Java, for access in  
other modules, where the spellings are formed by rules other than  
those governing (non-exotic) Java identifiers.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090122/2f3abd08/attachment.html 

From szegedia at gmail.com  Thu Jan 22 09:46:30 2009
From: szegedia at gmail.com (Attila Szegedi)
Date: Thu, 22 Jan 2009 18:46:30 +0100
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <497838F5.80204@univ-mlv.fr>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>	<49777F26.9070601@univ-mlv.fr>
	<49778587.9090704@sun.com>	<4977903C.9030902@univ-mlv.fr>
	<49779AF2.6010904@sun.com>
	<255947C3-9949-4835-B4B8-8D0C8BED08B2@sun.com>
	<497838F5.80204@univ-mlv.fr>
Message-ID: <0F1511D6-58E6-41FB-869D-346EACADAC2B@gmail.com>

On 2009.01.22., at 10:14, R?mi Forax wrote:

> With your RFE,  @#"{}"({@#"@"()}) will be a valid annotation and not a
> swearword :)

Well, it's probably a valid Perl program too, so why not allow it...

Attila.



From John.Rose at Sun.COM  Thu Jan 22 14:44:39 2009
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 22 Jan 2009 14:44:39 -0800
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <0F1511D6-58E6-41FB-869D-346EACADAC2B@gmail.com>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
	<49777F26.9070601@univ-mlv.fr> <49778587.9090704@sun.com>
	<4977903C.9030902@univ-mlv.fr> <49779AF2.6010904@sun.com>
	<255947C3-9949-4835-B4B8-8D0C8BED08B2@sun.com>
	<497838F5.80204@univ-mlv.fr>
	<0F1511D6-58E6-41FB-869D-346EACADAC2B@gmail.com>
Message-ID: <8309F0B5-B116-4F43-98D8-B62E58270EC2@sun.com>

Indeed. Invokedynamic is abusable in propotion to its power, and  
someone could encode a whole foreign (or Java!) program in the method  
name of a single ID call. The MOP will need to develop standards for  
the syntax and design of those names; that's why I reserved the colon  
':' char in the mangling proposal.

One could write this, I suppose, to denote a statically defined online  
script, which the MOP would cause to be compiled at first execution  
(i.e. call site link time).

Dynamic.#"javascript: print 'hello world'"();

There is an URL-like quality to such names. More conservatively, I  
think we'll see names like #"get:length", #"set:parent",  
#"super:init", #"op:%", and other cases where the invocation is not a  
context insensitive named method call, but where there is an  
additional intention/aspect in the surrounding syntax.

-- John  (on my iPhone)

On Jan 22, 2009, at 9:46 AM, Attila Szegedi <szegedia at gmail.com> wrote:

> On 2009.01.22., at 10:14, R?mi Forax wrote:
>
>> With your RFE,  @#"{}"({@#"@"()}) will be a valid annotation and  
>> not a
>> swearword :)
>
> Well, it's probably a valid Perl program too, so why not allow it...
>
> Attila.
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From glaforge at gmail.com  Fri Jan 23 01:01:56 2009
From: glaforge at gmail.com (Guillaume Laforge)
Date: Fri, 23 Jan 2009 10:01:56 +0100
Subject: NetBeans support for proposed small language extensions
In-Reply-To: <63920F4D-A044-42CD-8B33-C0538BECB364@sun.com>
References: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>
	<49777F26.9070601@univ-mlv.fr> <49778587.9090704@sun.com>
	<4977903C.9030902@univ-mlv.fr> <49779AF2.6010904@sun.com>
	<255947C3-9949-4835-B4B8-8D0C8BED08B2@sun.com>
	<497838F5.80204@univ-mlv.fr>
	<63920F4D-A044-42CD-8B33-C0538BECB364@sun.com>
Message-ID: <197b18fc0901230101j6e446088w6aeff3f151df78fc@mail.gmail.com>

On Thu, Jan 22, 2009 at 12:04 PM, John Rose <John.Rose at sun.com> wrote:
> On Jan 22, 2009, at 1:14 AM, R?mi Forax wrote:
>
> In that case, you don't need '#',  Dynamic."setcar!"(aCons, aValue)
>
> is not ambiguous. It will work with all qualified access to field and
>
> method.
>
> That's what we did in Groovy; it works well there.  Java needs to be a
> little more formal, I think, and make a clear distinction between string
> literals and identifiers.

Interesting, I'm not sure I really understand why Java would need to
be "more formal", and in what way using # would make things more
formal.
I've come to be used to the Groovy way of doing things (but of course
I'm biased), and I quite like this idea (yours!!!) to have "quoted
identifiers".

Currently, in Groovy, the most advertised one is when using single or
double quotes, but actually, Groovy allows different syntaxes:

System.'out'.println "hello"
System."out".println "hello"
System./out/.println "hello"
System.'''out'''.println "hello"
System."""out""".println "hello"

Basically, all String literal forms are allowed.
And we also allow these ones:

System.(out).println "hello"
System.{out}.println "hello"

Which means we can also use some expressions inside like:

System.('o' + 'u' + 't').println "hello"

Of interest as well is that when the String literal is a GString, you
can interpolate variables!

def var = 'out'
System."${var}".println "hello"
System."""${var}""".println "hello"
System./${var}/.println "hello"

We obviously don't need all these forms, but since String and GStrings
are allowed as quoted identifiers, all these forms are possible.

I quite liked the idea of String quoted identifiers, as they really
allow any kind of identifier name to be used, pretty cleanly IMHO, and
I feel the sharp sign is a bit odd in that context. But it's perhaps
just a matter of taste ;-)

-- 
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


From John.Rose at Sun.COM  Sat Jan 24 15:43:41 2009
From: John.Rose at Sun.COM (John Rose)
Date: Sat, 24 Jan 2009 18:43:41 -0500
Subject: Starting work on an Interface Injection prototype
In-Reply-To: <9997d5e60812110255p1edc3be7lb7af3d625b200a9c@mail.gmail.com>
References: <9997d5e60812110255p1edc3be7lb7af3d625b200a9c@mail.gmail.com>
Message-ID: <D15A40BF-79AD-4541-8576-442D5BCAE037@sun.com>

On Dec 11, 2008, at 2:55 AM, Tobias Ivarsson wrote:

> John: last time you and I spoke about this you said that you were  
> going to start working on some core implementation details. Have  
> you had time to look into that?
> If not - that's ok, I'll go ahead anyway, I just don't want to be  
> duplicating too much of the effort.

I sent you my current sketches the other day; I hope they help.  Feel  
free to ask me what I'm intending in them, or else what design  
alternative you favor.

Let's use the follow public page as a notebook on the project:
   http://wikis.sun.com/display/mlvm/InterfaceInjection

This page also has information about how interfaces work:
   http://wikis.sun.com/display/HotSpotInternals/InterfaceCalls

> If you have looked into it, I would love if you could share the  
> material you have, in terms of source code or analytical documents.  
> But don't feel the need to work on this now if you haven't before  
> just because I'm starting this project - I'll be able to manage  
> just fine on my own (Although I might drop you an e-mail or two  
> with questions).

Basic idea is that each klass structure already includes (allocated  
inline) a 2-dimensional ragged table of its statically defined  
interfaces.  In meth.patch I've rationalized this a little to prepare  
for your work.  I put more extensive notes on the wiki page mentioned  
above.

Best wishes,
-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090124/fb322d76/attachment.html 

From thobes at gmail.com  Sun Jan 25 06:57:39 2009
From: thobes at gmail.com (Tobias Ivarsson)
Date: Sun, 25 Jan 2009 15:57:39 +0100
Subject: Starting work on an Interface Injection prototype
In-Reply-To: <D15A40BF-79AD-4541-8576-442D5BCAE037@sun.com>
References: <9997d5e60812110255p1edc3be7lb7af3d625b200a9c@mail.gmail.com>
	<D15A40BF-79AD-4541-8576-442D5BCAE037@sun.com>
Message-ID: <9997d5e60901250657s1529e226k2abae455668b9c80@mail.gmail.com>

On Sun, Jan 25, 2009 at 12:43 AM, John Rose <John.Rose at sun.com> wrote:

> On Dec 11, 2008, at 2:55 AM, Tobias Ivarsson wrote:
>
> *John*: last time you and I spoke about this you said that you were going
> to start working on some core implementation details. Have you had time to
> look into that?
> If not - that's ok, I'll go ahead anyway, I just don't want to be
> duplicating too much of the effort.
>
>
> I sent you my current sketches the other day; I hope they help.  Feel free
> to ask me what I'm intending in them, or else what design alternative you
> favor.
>

I noticed that, I have read through your patch once. Sadly I spent
Thursday-Friday being sick, and then had family visiting Saturday. So I
haven't done more since then. From what I have looked at it looks very
similar to my ideas, the main difference being naming, I am a bit more
verbose than you are. I liked the way you used arrays to represent each
extension record, it ties in more easily with existing systems, such as
garbage collection. I defined a C++ structure for the extension records, but
I'll change that since I think your approach is more elegant there.

I have been thinking about one thing in the JITing phase, that I have not
implemented. If interfaces are marked as being injectable or not, then we
would not have to emit the code for looking up the interface in the
extension list if it's not injectable. To do this the method that emits the
instructions needs to have access to the klass representing the interface.
Is that possible? Is it desirable?

>
> Let's use the follow public page as a notebook on the project:
>   http://wikis.sun.com/display/mlvm/InterfaceInjection
>
> This page also has information about how interfaces work:
>   http://wikis.sun.com/display/HotSpotInternals/InterfaceCalls
>
> If you have looked into it, I would love if you could share the material
> you have, in terms of source code or analytical documents. But don't feel
> the need to work on this now if you haven't before just because I'm starting
> this project - I'll be able to manage just fine on my own (Although I might
> drop you an e-mail or two with questions).
>
>
> Basic idea is that each klass structure already includes (allocated inline)
> a 2-dimensional ragged table of its statically defined interfaces.  In
> meth.patch I've rationalized this a little to prepare for your work.  I put
> more extensive notes on the wiki page mentioned above.
>

Excellent notes, I'll add to that page as well.

>
> Best wishes,
> -- John
>
> _______________________________________________
> 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/20090125/74ea9f8a/attachment.html 

From John.Rose at Sun.COM  Mon Jan 26 15:00:38 2009
From: John.Rose at Sun.COM (John Rose)
Date: Mon, 26 Jan 2009 15:00:38 -0800
Subject: Starting work on an Interface Injection prototype
In-Reply-To: <9997d5e60901250657s1529e226k2abae455668b9c80@mail.gmail.com>
References: <9997d5e60812110255p1edc3be7lb7af3d625b200a9c@mail.gmail.com>
	<D15A40BF-79AD-4541-8576-442D5BCAE037@sun.com>
	<9997d5e60901250657s1529e226k2abae455668b9c80@mail.gmail.com>
Message-ID: <BA608535-E035-4256-A2BB-512C1E8B41E7@sun.com>

On Jan 25, 2009, at 6:57 AM, Tobias Ivarsson wrote:

> I liked the way you used arrays to represent each extension record,  
> it ties in more easily with existing systems, such as garbage  
> collection. I defined a C++ structure for the extension records,  
> but I'll change that since I think your approach is more elegant  
> there.

Maybe not elegant, but workable; the choice is based on painful  
experience.  It is surprisingly difficult to introduce a  
fundamentally new heap node type; you have to cut in new code in many  
places.  (I'm working on a back burner project to make common cases  
of this a little easier; watch for "mixed arrays".)

> I have been thinking about one thing in the JITing phase, that I  
> have not implemented. If interfaces are marked as being injectable  
> or not, then we would not have to emit the code for looking up the  
> interface in the extension list if it's not injectable. To do this  
> the method that emits the instructions needs to have access to the  
> klass representing the interface. Is that possible? Is it desirable?

Customizing code like that is usually only done by the JIT's  
optimizer.  (Esp. the server JIT.)  The interpreter can usually  
afford (until proven otherwise!) to use the most generic code sequences.

There are five places where interface types must be checked by the JIT:

1. invokeinterface
2. instanceof
3. checkcast
4. checkcast implicit in aastore checks
5. reflective versions of 1, 2, or 3.

In cases 1, 3, and 4, there is no strong need to customize for non- 
injectable interfaces, because the cost of failure is always an  
expensive exception, so it doesn't matter if you did a useless check  
of the extension records.

In case 2, there is definitely a need for a negative supertype cache  
in class Klass.

In case 5, if there is a JIT intrinsic which folds the reflective  
idiom to a non-reflective one, then it can be reduced to one of the  
previous cases (1,2,3).  Otherwise, it is probably slow, and can be  
treated in full generality all the time.  A possible exception is  
that the negative supertype cache should be consulted for reflective  
instanceof.

Cases 4 and 5 are interesting in that the interface type being tested  
against is non-constant (aastore checks against a varying array  
element type).  In those cases, you either use full generality all  
the time, or use both code sequences, selected by a dynamic test for  
injectability.

Bottom line, per case:
1. always check for extension records
2. always use the negative cache (after fast positive tests), and  
customize the code in the JIT (GraphKit::gen_subtype_check)
3. customize in the JIT; negative cache buys nothing
4. customize in the JIT if possible; negative cache buys nothing
5. let the JIT do its thing for intrinsics; use the negative cache  
for Class.isInstance and Class.isAssignableFrom

-- John


From John.Rose at Sun.COM  Mon Jan 26 15:17:12 2009
From: John.Rose at Sun.COM (John Rose)
Date: Mon, 26 Jan 2009 15:17:12 -0800
Subject: Starting work on an Interface Injection prototype
In-Reply-To: <BA608535-E035-4256-A2BB-512C1E8B41E7@sun.com>
References: <9997d5e60812110255p1edc3be7lb7af3d625b200a9c@mail.gmail.com>
	<D15A40BF-79AD-4541-8576-442D5BCAE037@sun.com>
	<9997d5e60901250657s1529e226k2abae455668b9c80@mail.gmail.com>
	<BA608535-E035-4256-A2BB-512C1E8B41E7@sun.com>
Message-ID: <863B9C5B-E825-4A5A-B758-218E2DB5092C@sun.com>

Uh, that was the sort of thing that belongs on the wiki.  I put it  
there:

   http://wikis.sun.com/display/mlvm/ 
InterfaceInjection#InterfaceInjection-Compiletimeoptimizations

(Trying to shift my habits...)

It's a wiki; go ahead and add to it!

-- John


From john.rose at sun.com  Tue Jan 27 19:20:02 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 28 Jan 2009 03:20:02 +0000
Subject: hg: mlvm/mlvm: more robust build instructions
Message-ID: <20090128032002.D03B6E32A@hg.openjdk.java.net>

Changeset: 0bf6d77bfb0b
Author:    jrose
Date:      2009-01-27 19:15 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/0bf6d77bfb0b

more robust build instructions

! README.txt
+ make/Makefile
! make/current-release.sh
! make/each-patch-repo.sh
! make/link-patch-dirs.sh



From john.rose at sun.com  Tue Jan 27 19:21:21 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 28 Jan 2009 03:21:21 +0000
Subject: hg: mlvm/mlvm/hotspot: more robust build instructions
Message-ID: <20090128032121.5F3FCE32F@hg.openjdk.java.net>

Changeset: 232a5bd9f4f8
Author:    jrose
Date:      2009-01-27 19:16 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/232a5bd9f4f8

more robust build instructions

! series



From john.rose at sun.com  Tue Jan 27 19:22:37 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 28 Jan 2009 03:22:37 +0000
Subject: hg: mlvm/mlvm/jdk: more robust build instructions
Message-ID: <20090128032237.2BA11E334@hg.openjdk.java.net>

Changeset: bab113128656
Author:    jrose
Date:      2009-01-27 19:16 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/bab113128656

more robust build instructions

! series



From john.rose at sun.com  Tue Jan 27 19:23:48 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 28 Jan 2009 03:23:48 +0000
Subject: hg: mlvm/mlvm/langtools: 2 new changesets
Message-ID: <20090128032349.05701E339@hg.openjdk.java.net>

Changeset: 3caf48a8737b
Author:    jrose
Date:      2009-01-27 18:44 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/3caf48a8737b

meth: addendum to previous revision

! meth.txt

Changeset: 2a12b4fbe111
Author:    jrose
Date:      2009-01-27 19:16 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/2a12b4fbe111

more robust build instructions

! series



From john.rose at sun.com  Thu Jan 29 14:19:44 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 29 Jan 2009 22:19:44 +0000
Subject: hg: mlvm/mlvm/hotspot: 2 new changesets
Message-ID: <20090129221944.389F7E411@hg.openjdk.java.net>

Changeset: df387891ff76
Author:    jrose
Date:      2009-01-29 14:18 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/df387891ff76

anonk: move source files to JDK

! anonk.proj.patch

Changeset: f7d1fffbe8eb
Author:    jrose
Date:      2009-01-29 14:18 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f7d1fffbe8eb

meth: move source files to JDK

! meth.proj.patch



From john.rose at sun.com  Thu Jan 29 14:21:58 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 29 Jan 2009 22:21:58 +0000
Subject: hg: mlvm/mlvm/jdk: 2 new changesets
Message-ID: <20090129222158.2595FE41E@hg.openjdk.java.net>

Changeset: 4dab500eb86f
Author:    jrose
Date:      2009-01-29 13:53 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4dab500eb86f

anonk: move source files to JDK

! anonk.patch
! series

Changeset: d6ba74ad1000
Author:    jrose
Date:      2009-01-29 13:54 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/d6ba74ad1000

meth: move source files to JDK

! meth.patch
! series