Thanks, Yuri; that's a good negative test.
The problem with allowing that BSM registration is that racing threads
can attempt to use indy sites before a BSM is installed. It's minor
problem, arguably the user's fault not ours, but I think it's both
harmless and helpful to require the BSM
Unless someone requests a meeting today, I will not be present in the
JCP room after 1:30, so I can go to the Hotspot Inside Out JVM BOF.
-- John
On Jun 4, 2009, at 11:50 AM, John Rose wrote:
From just after 12:00 today until 2:00 I'll be working quietly in
the Nob Hill room on the 4th
From just after 12:00 today until 2:00 I'll be working quietly in the
Nob Hill room on the 4th floor of the Intercontinental. This room has
been reserved by the JCP for EG use; let's use it to talk JSR 292.
-- John
P.S. Previously sent info:
June 3, 2009 from 9:00 AM to 11:00 AM
June 4,
Changeset: a643b6f41624
Author:jrose
Date: 2009-05-28 02:51 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a643b6f41624
meth: dropArguments working, varargs handling improved
! indy.patch
___
mlvm-dev mailing list
Changeset: 083732b6300a
Author:jrose
Date: 2009-05-28 02:51 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/083732b6300a
meth: dropArguments working, varargs handling improved
! netbeans/meth/test/jdk/java/dyn/MethodHandlesTest.java
From the issue list:
ISSUE INSTRUCTION-PADDING: The invokedynamic instruction needs to
be 5 bytes long (for some JVM implementations, to allow embedded
coding of call site identity). GIven that, shall the final two
bytes be (a) required to be zero and reserved for future use, or (b)
Changeset: 16e8d2a2f373
Author:jrose
Date: 2009-05-27 02:15 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/16e8d2a2f373
meth: MethodHandles.spreadArguments passes unit test
! netbeans/meth/test/jdk/java/dyn/MethodHandlesTest.java
Changeset: a5787f9c78d9
Author:jrose
Date: 2009-05-27 02:14 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a5787f9c78d9
meth: MethodHandles.spreadArguments passes unit test
! indy.patch
___
mlvm-dev mailing list
Thanks, Remi; will do. -- John
On May 27, 2009, at 9:12 AM, Rémi Forax wrote:
last line should be :
return convertArguments(token, gguard, type, gtype, null);
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: d6e69f64cd3e
Author:jrose
Date: 2009-05-27 13:00 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/d6e69f64cd3e
meth: guardWithTest typing bug
! netbeans/meth/test/jdk/java/dyn/MethodHandlesTest.java
___
mlvm-dev mailing
On May 27, 2009, at 9:16 PM, Charles Oliver Nutter wrote:
we *must* give the keys to the castle to language
developers, by opening up the very guts of the JVM's optimizing
pipeline
I agree that static type checking for method handles would be very
useful, but the language design work is
I just pushed a fix for this. -- John
On May 19, 2009, at 3:37 PM, John Rose wrote:
I've reproduced your crash from the command line; thanks for the clean
instructions.
The crash is for:
def foo(a); end; a = 1; while a 1_000_000; foo(a); a += 1; end
On May 18, 2009, at 4:01 PM
On May 19, 2009, at 3:37 PM, Charles Oliver Nutter wrote:
Woah, now that's wild. Can you elaborate on that at all? Would the MHs
essentially be the nodes of an IR?
It certainly deserves elaboration. My previous message gave a few
more points about combineArguments.
Fredrik's blog entry of
On May 18, 2009, at 10:40 AM, Christian Thalinger wrote:
Are the patches in MLVM current? It seems I'm missing classes and
methods:
Yes, the patches are current. For example, the patch
indy-6829144.patch contains the (new) definition of InvokeDynamic.
This is identical with the push
Thanks for giving it a spin. Your test case is a good one, but there
seem to be logic errors.
This line:
site.setTarget(target);
should probably be
site.setTarget(this);
I'm surprised you don't get an error at that point. Your target takes
2 string args, while the indy site takes just
On May 18, 2009, at 2:22 PM, Yehuda Katz wrote:
I had tried that before; when I do that, I get:
Exception in thread main java.dyn.WrongMethodTypeException:
Bound[unknown(java.lang.String)java.lang.String]
at java.dyn.CallSite.checkTarget(CallSite.java:149)
at
My first use of git was a couple days ago, to pull jruby from kenai.
So I'm a git noob. (Too bad about ruby mercurial.)
That said, can I have a recipe (script) for pulling, building your
hacked version of jruby, and then for running your test case(s)?
(From NetBeans, if possible, so I
I hope b59 smells better. I just pushed the changes I've chosen for
b59 to the patch repo.
I am working on other changes too, but I am in point-fix mode, as JDK7
M3 settles down for JavaOne.
My goal at the moment is to find workarounds for broken stuff, so as
not to be making widespread
On May 12, 2009, at 3:46 PM, Rémi Forax wrote:
I've found that if you convert the leading argument of the method
handler,
you have to cast the leading argument of MethodHandle.invoke() too.
Yes, that's because method handle invocation sites do not allow
variation in the target method
BTW, I filed bug 6839872 against this poor choice. -- John
On May 12, 2009, at 7:29 AM, Rémi Forax wrote:
The compiler is confused by the fact that java.dyn.MethodHandle
inherits
from sun.dyn.MethodHandleImpl
which is not visible.
We found another reason to change that design :)
On May 12, 2009, at 4:55 PM, Rémi Forax wrote:
Ok, that why I haven't found that bug before b58 because
my old tests was also on the boot class path.
Yep, I'm in the same boat; I've been living out of incremental builds
and -Xbcp options for a long time. It has been a scramble for me in
Changeset: e77c75b8e896
Author:jrose
Date: 2009-05-07 00:17 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e77c75b8e896
indy: support invokedynamic in pack200 encoder
+ indy.pack.patch
! series
___
mlvm-dev mailing list
On May 5, 2009, at 10:48 PM, Fredrik Öhrström wrote:
So my question was, and still is, :-) , why would you
call a constructor through a MethodHandle?
It would let you emulate the super(...) call in a language which needs
to make a subclass of some Java class with a non-trivial constructor,
Changeset: 556edafa03fd
Author:jrose
Date: 2009-05-06 18:57 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/556edafa03fd
meth, quid: update patch repo consistently with yesterday's push to JDK7 of
6829189
! meth-6829189.patch meth.patch
! meth.txt
!
Changeset: a5f19be63c32
Author:jrose
Date: 2009-05-06 19:45 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a5f19be63c32
meth, indy: update patch repo consistently with yesterday's push to JDK7 of
6829144
+ anonk-6829144.patch
- anonk.patch
! indy-6829144.patch
Changeset: 62704edcb9f0
Author:jrose
Date: 2009-05-06 20:03 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/62704edcb9f0
dyncast: add experimental patch
+ dyncast.patch
Changeset: a63c9ae3622a
Author:jrose
Date: 2009-05-06 20:03 -0700
URL:
Changeset: 2e0a61f2128a
Author:jrose
Date: 2009-05-06 19:59 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/2e0a61f2128a
meth: restart patch empty after 6829189
+ meth.patch
! series
___
mlvm-dev mailing list
I have been updating the InvokeDynamicDemo toy project from my blog
(and the meth/indy software in general).
Here's the driver routine for that demo:
import java.dyn.*;
import static java.dyn.MethodHandles.*;
import static java.dyn.MethodType.*;
public class Main {
static final Class[]
Changeset: a0dcfbefe123
Author:jrose
Date: 2009-04-29 21:04 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/a0dcfbefe123
meth, quid: consolidate changes for 6829189
! dyncast.patch
! meth.patch
! nb-javac/dyncast.patch
! nb-javac/meth.patch
! quid.patch
! series
On May 2, 2009, at 4:06 PM, Rémi Forax wrote:
Hi John, hi all,
Doing some testing, I've found that a registerBootstrapMethod that
take
the a class
that will contain a linkage static method and a method name is
convenient.
public static
void registerBootstrapMethod(Class?
On May 2, 2009, at 5:55 PM, Rémi Forax wrote:
I badly need it.
I want a bootstrap method, a factory method of CallSite because
depending on invokedynamic name I want to store different kind of
profile.
I think that one bootstrap method that can return different CallSite
implementations
The majority of indy.patch has entered the JDK7 VM at my workgroup's
integration repo, today at about 4:00AM PDT:
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/be93aad57795
More to come, as we hammer on the spec, Java API, and initial apps.
-- John
On Apr 10, 2009, at 11:23 AM, Ben Evans wrote:...BUILD SUCCESSFULTotal time: 25 secondsgnumake: *** [build] Error 2Can you say why gnumake is reporting error status 2? Did ant complain somewhere? When I try an incremental rebuild, the last output looks something like
On Apr 10, 2009, at 12:10 PM, Charles Oliver Nutter wrote:
We really need some enterprising non-Sun individual to start
publishing
binaries (hint, hint).
Indeed. (nudge, nudge)
BTW, the main body of method handle support (all meth-.patch) is
now pushed to a sub-integration area
On Apr 10, 2009, at 12:16 PM, Charles Oliver Nutter wrote:
Is there any possibility of the Java-level APIs getting pushed out
as a
sun.something package? I know we can't shove java.* things without the
JSR, but if there were any chance of a hotspot-only meth/indy getting
into Java 6 some
On Apr 5, 2009, at 1:10 AM, Charles Oliver Nutter wrote:
Ok, here's my status. It turns out that the standard instructions are
now basically working, and I'm in the process of modifying JRuby's
invokedynamic support for the changes over the past few months.
Here's a heads-up: The JIT support
Changeset: daca8baee5f4
Author:jrose
Date: 2009-04-07 02:06 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/daca8baee5f4
meth: update with round 3 of review
! meth.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: 8b5cc1a371e9
Author:jrose
Date: 2009-04-06 03:29 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8b5cc1a371e9
indy: more demos work
! indy.patch
+ indy.verify.patch
! series
___
mlvm-dev mailing list
Changeset: 41bc9c25b6d0
Author:jrose
Date: 2009-04-06 03:30 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/41bc9c25b6d0
update build instructions for bsd-port
! README.txt
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: d88356a6b5e8
Author:jrose
Date: 2009-04-06 03:27 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d88356a6b5e8
indy: more demos work
! indy.patch
! indy.txt
! meth.patch
! series
___
mlvm-dev mailing list
Changeset: f7eab0ec5cfc
Author:jrose
Date: 2009-04-06 03:31 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/f7eab0ec5cfc
quid: fix escape-sequence bug
! quid.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: cb6fe4452c67
Author:jrose
Date: 2009-04-03 00:28 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/cb6fe4452c67
remove integrated patches
- gibbons.patch
- gibbons.txt
Changeset: 274a81fa4e16
Author:jrose
Date: 2009-04-03 00:28 -0700
URL:
Changeset: ef70a7045609
Author:jrose
Date: 2009-04-03 00:59 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ef70a7045609
meth, indy: rebase to bsd-port and latest JVM changes
! tailc.txt
___
mlvm-dev mailing list
Adjusting and testing the patch... Looks like it works.
I found that this line in my top-level build.sh script helps when I am
rebuilding the JVM from a non-clean forest:
rm -f $(find build -name _precompiled.incl.gch)
Also, because I'm not building the whole forest, this line seems to be
Changeset: 3c642244cfb8
Author:jrose
Date: 2009-04-03 02:53 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/3c642244cfb8
meth: update test project
! meth.proj.patch
! series
___
mlvm-dev mailing list
Changeset: f1e1022079f2
Author:jrose
Date: 2009-04-03 03:01 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f1e1022079f2
meth: remove spurious makefile change
! meth.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: c3c0de253c82
Author:jrose
Date: 2009-04-03 02:34 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/c3c0de253c82
meth, indy: rebase to bsd-port and latest JVM changes; pull indy changes out of
meth
! indy.patch
! meth.patch
! series
Changeset: 5c5527e09ffe
Author:jrose
Date: 2009-04-03 15:15 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5c5527e09ffe
meth, anonk: project files work with ant and/or netbeans
! anonk.proj.patch
! meth.proj.patch
! series
On Mar 29, 2009, at 10:06 AM, Charles Oliver Nutter wrote:
John: I think indy is still not quite functional on bsd-port, yes?
Maybe
I should just focus on playing with method handles for now?
That is correct; I'm still working on refreshing it. Method handles
are fine, I think. -- John
Changeset: 87f5d92f668d
Author:jrose
Date: 2009-03-27 01:39 -0500
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/87f5d92f668d
dyncast: implicit Dynamic - Object
! dyncast.patch
! nb-javac/dyncast.patch
___
mlvm-dev mailing list
Changeset: 023ca8953eeb
Author:jrose
Date: 2009-03-26 19:52 -0500
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/023ca8953eeb
rebase to bsd-port
! quid.patch
Changeset: 7bb498e01708
Author:jrose
Date: 2009-03-26 19:53 -0500
URL:
Changeset: e4b6cde00a47
Author:jrose
Date: 2009-03-21 23:46 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e4b6cde00a47
meth: rebase to bsd-port, and split according to upstream pushes
+ meth-6655638.patch
+ meth-asm-6812678.patch
+ meth-ilookup-6812831.patch
+
Changeset: 590fe9969f83
Author:jrose
Date: 2009-03-21 23:57 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/590fe9969f83
inti: checkpoint; compiles
Contributed-By: thobe (Tobias Ivarsson)
+ inti.patch
+ inti.txt
___
mlvm-dev
Changeset: b935492d6b25
Author:jrose
Date: 2009-03-21 23:59 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b935492d6b25
inti: checkpoint; compiles
Contributed-By: thobe (Tobias Ivarsson)
+ inti.patch
___
mlvm-dev mailing list
Is there any way to make this easier short of rebasing the mlvm
patches to bsd-port?
The mlvm patches are current based at the OpenJDK hotspot master:
http://hg.openjdk.java.net/jdk7/hotspot/hotspot
It's going to get even trickier as my current train of pushes trickles
up to the master
On Mar 16, 2009, at 7:27 AM, Ben Evans wrote:
Or is the intent that the new form of wide will never appear
in .class files, but only in code which has been generate
dynamically, ie so that this is a private implementation detail to
HotSpot and can't cause problems to other JVMs?
As
On Mar 16, 2009, at 7:27 AM, Ben Evans wrote:
The idea being that the wide opcode indicates that this call should
be optimised as a tail call, and that the interpreter part of
HotSpot will then (if allowed by protection restrictions) rewrite
the current native stack frame rather than
On Mar 6, 2009, at 1:28 AM, Tobias Ivarsson wrote:
The type test injection point was a mess. Today I just collapsed
about 20 copies of the assembly code down to 2 copies (sparc, x86). I
would hate to see you tackle that part of it without today's
refactoring.
Oh, cool, so perhaps it
On Mar 6, 2009, at 12:12 AM, Tobias Ivarsson wrote:
The status is that I have implemented injection for invokeinterface.
There is still some testing to be done there and then I'll move on
to the other injection points.
Nice! Want to post it as-is before PyCon, so people can look at it
On Mar 6, 2009, at 1:28 AM, Tobias Ivarsson wrote:
As I said it's work in progress, not much testing done, but it does
compile. There are a also a few comments that are only my personal
todo-notes, most of these are tagged with THOBE (makes them easy
for me to grep for).
That's fine;
(CC-ed).
Both of the latter changes should help with interface injection
prototyping. (Hi, Tobias :-)
-- John
Begin forwarded message:
From: John Rose john.r...@sun.com
Date: March 5, 2009 5:54:04 PM PST
To: hotspot compiler hotspot-compiler-...@openjdk.java.net
Subject: for review (M
On Feb 17, 2009, at 2:41 AM, Tobias Ivarsson wrote:
When the JRuby runtime recevies an object from PHP it casts it to
IRubyObject (the main JRuby type) which is an injectable interface.
If the class of the object does not already implement IRubyObject
the injector for the interface is
I've posted a simple working recipe for an invokedynamic use case,
here:
http://blogs.sun.com/jrose/entry/simple_java_linkage_with_invokedynamic
If you've tried to build the JVM from the indy.patch lately, you know
it is rather out of date. I'm working to refresh that, so the blog
I just updated the table of MLVM subprojects.
http://openjdk.java.net/projects/mlvm/subprojects.html
The last column shows implementation status, and if you look at it
you'll see that a lot has changed in recent months. Thanks!
Best wishes,
-- John
On Feb 11, 2009, at 12:24 AM, Arnold Schwaighofer wrote:
At this point i will publish a polished set of patches.
A number of people are looking forward to that; thanks.
The design
notes date from the very beginning of the implementation. I should
probably have deleted them. When my thesis
Changeset: 8d6d5a50f374
Author:jrose
Date: 2009-02-10 15:03 -0800
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8d6d5a50f374
tailc: initial revision working with JITs
Contributed-By: arnold_s (Arnold Schwaighofer)
+ tailc.patch
+ tailc.txt
Hey, Arnold, I just reintegrated the latest patch I had from you and
posted it to the mlvm repo.
I also stuck your design notes (from your patch) on the wiki, FWIW:
http://wikis.sun.com/display/mlvm/TailCalls
I'd be happy to take the next layer when you have a good moment to
shoot it my
On Feb 5, 2009, at 2:17 AM, Rémi Forax wrote:
It's exactly like the way .class is/was compile(d) by javac.
Until 1.5, .class was emulated by generating the same private method
on all toplevel class.
If we don't have LDC MethodHandle, we (all language developers)
will rely on a private method
On Feb 5, 2009, at 2:04 AM, Rémi Forax wrote:
BTW, the Java code of bound method can be simplified.
In my opinion, a bound method handle is a direct method handle plus an
object at argument zero.
Yes. That is true, because there is no (net) stack motion, as the MH
which is the receiver of
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:
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:
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
___
mlvm-dev mailing list
mlvm-dev@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:
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
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
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.
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
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
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
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:
The langtools stuff is not yet refreshed against the current build.
Thanks for the diffs.
By the way, the indy patch is not refreshed either. The next update
will change the instruction format to move away from the
representation which uses invokeinterface and toward a receiverless
Changeset: 1ba2ea4e1a1a
Author:jrose
Date: 2008-12-24 20:17 -0800
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/1ba2ea4e1a1a
Refresh hotspot to build 42
! meth.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
Changeset: 1d42dc25d9e3
Author:jrose
Date: 2008-12-24 19:53 -0800
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1d42dc25d9e3
meth: rebase to b42; improve implementation
! meth.patch
! meth.txt
! series
___
mlvm-dev mailing list
On Dec 17, 2008, at 2:16 PM, Iulian Dragos wrote:
This is where we're heading. But the current implementation is using
the JSR292 convention, so for my tests I should still use it?
For now, yes. I won't turn it off right away.
I noticed a very useful method mentioned in the JSR is missing
On Dec 17, 2008, at 12:13 PM, Rémi Forax wrote:
Iulian Dragos a écrit :
I noticed several differences between what JSR 292
(http://jcp.org/en/jsr/detail?id=292) says and the current
implementation. I know this is work in progress, but at least one
difference seems small enough to be an
(Wow, guess I must be furious!)
On Dec 17, 2008, at 1:09 PM, John Rose wrote:
That's right, Remi. I'm working furiously on both spec. and implem.
furiously, aiming to get a refresh of both by Christmas.
___
mlvm-dev mailing list
mlvm-dev
We don't make an invokedynamic.jar. (Unless Remi does?) I think you
are looking for JSR 223, not JSR 292.
Good luck,
-- John
On Dec 9, 2008, at 10:56 AM, Bui, Phillip wrote:
I look for the source code to build invokedynamic.jar for Jruby 1.1.5.
Do you know the location ?
Thanks,
Phillip
Here's a small but important milestone: The contents of the an mlvm
patch to the JVM, hotspot/anonk.patch, have been (after testing and
review) pushed to a HotSpot integration repository:
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a45484ea312d
Unlike the JSR 292 work on
On Oct 27, 2008, at 5:38 PM, Rémi Forax wrote:
In general, you use MHs.insertArgument to build bound method handles
to perform language-specific adaptation and dispatch. The attached
code (using the bound-in data to fill in free variables) needs to
perform the language-specific tests and
On Oct 9, 2008, at 1:49 PM, Rémi Forax wrote:
With this encoding, you have a receiveless 5-byte opcode.
Good point. But, someone is sure to complain that the normal uses of
the opcode do not allow null. Then we get around to those other
designs we talked about at the Summit, where the
Changeset: ecddad94fb3f
Author:jrose
Date: 2008-09-07 00:38 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/ecddad94fb3f
initial subproject for exotic symbols
+ .hgignore
+ quid.patch
+ quid.txt
+ series
Changeset: 8ae38094aaa9
Author:jrose
Date: 2008-09-09
Changeset: c1612cfa
Author:jrose
Date: 2008-09-09 13:12 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/c1612cfa
quid: add new bug ID, update comment page
! quid.txt
___
mlvm-dev mailing list
Changeset: bb305998312e
Author:jrose
Date: 2008-09-07 00:42 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/bb305998312e
anonk, meth, indy: first working JRuby support
also, rebase to http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/jdk7-b34
! anonk.patch
!
Changeset: e65430d0399f
Author:jrose
Date: 2008-09-06 19:40 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e65430d0399f
meth: update test project to do assertion tests
! meth.proj.patch
___
mlvm-dev mailing list
Hi, Ulf. I whitelisted you on the mailing list, since you are not
yet a member and it was blocking you.
You probably want to join, in order to receive any responses from the
group.
JSR 292 is discussing bytecode modifications. Array init. is outside
the scope of JSR 292, so I don't
On Aug 30, 2008, at 9:05 AM, Nicholas Riley wrote:
I'm guessing this has only been tested on Solaris/Sun Studio? I tried
building with GCC 3.4 and 4.1 on Linux and ran into this error with
meth.patch applied:
Thanks for trying it out! You are right.
The current prototype works (with bugs)
Changeset: 0df7809c0e25
Author:jrose
Date: 2008-08-30 18:16 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0df7809c0e25
meth: fix some build problems for JPRT
! meth.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
of the same name, though.
And, you can buy monkey da vinci shirts here:
http://www.cafepress.com/monomal/248379
-- Chuck
John Rose wrote:
FYI: An important JSR 292 milestone. -- John
Begin forwarded message:
*From: *John Rose [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
*Date
Hello, colleagues. This month I'm hammering on method handle code in
the JVM. I'll do a checkpoint (push of partially working code) to
the repo. in a few days.
(As a second priority, I'm also working on a mixed array data
structure. The refactoring part of that code is out for review
On Jun 21, 2008, at 12:31 AM, Charles Oliver Nutter wrote:
How would invokedynamic work if we don't have compiled Java bytecode
anywhere to dispatch to? For example, JRuby is mixed mode right
now, and
some methods are interpreted (AST or various bytecode specs) while
some
methods get
601 - 700 of 706 matches
Mail list logo
