What Remi said. -- John
On May 26, 2011, at 5:09 PM, Rémi Forax wrote:
the major point of having the SwitchPoint API is,
like most of the API of java.lang.invoke,
that these API are/will be recognized and optimized by the VM.
___
mlvm-dev mailing
On May 26, 2011, at 5:18 PM, Charles Oliver Nutter wrote:
Some combination of
these flags will be enabled by default as they get optimized in
Hotspot. That should allow having things on as they're ready to be
on by default.
That's the way we do it in the JVM also, on works-in-progress which
That sounds right.
On May 26, 2011, at 6:31 PM, Charles Oliver Nutter wrote:
* For a descendant hierarchy of N classes, I'll need to do N
invalidateAll calls. This is not ideal, since those calls are very
heavy.
Fully optimized invalidations will use safepoints. The point of using an array
On May 25, 2011, at 3:23 AM, Christian Thalinger wrote:
I know that. That's why we need to find out where the problem is (some hints
below). Can someone provide a jar file of the current MLVM JSR 292 classes
(like John's meth.jar)?
I just posted it with the javadoc:
On May 25, 2011, at 9:31 AM, Charles Oliver Nutter wrote:
Build in progress! I'll let you know how it goes. How low is low in low
arity?
About 0-9.
Let's find the next bottleneck!
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
On May 23, 2011, at 5:43 PM, Charles Oliver Nutter wrote:
Well I have a prototype GWT in place, but I'm having trouble getting
invokeExact to work. As far as I can tell, incoming arguments should
match the handle type just fine, but I'm getting this error:
Hmm... I don't see the bug in your
On May 24, 2011, at 10:25 PM, Ola Bini wrote:
I don't use permuteArguments anywhere in my code, actually, but maybe
one of the other combinators is defined in terms of it?
No, it's stand-alone. Factoid: All the other combinators are order-stable with
respect to arguments.
I toyed with using
On May 23, 2011, at 11:45 AM, Charles Oliver Nutter wrote:
I did see fib_ruby compile and was able to get assembly dumps out, but
it performed terribly. I'll try to make extra sure everything's
jitting.
Ahh the joys of a mixed-mode runtime, eh?
Indeed. Anyway, thanks for pushing on this.
On May 23, 2011, at 2:19 PM, Charles Oliver Nutter wrote:
I'm working up a set of files that show JRuby compilation output, but
I noticed a couple things that might be interesting right now.
That looks promising. It seems something got bumped in our inlining logic. --
John
On May 23, 2011, at 2:26 PM, Charles Oliver Nutter wrote:
* GWT
GWT changed, but in a way that should make it easier (not harder) to inline.
That could be the problem.
The new format (using ricochet frames) is:
GWT(p,t,f)(*a) := ( selectAlternative(p(*a), t, f) ).invokeExact(*a)
where
On May 23, 2011, at 3:44 PM, Tom Rodriguez wrote:
I'd *love* for intermediate static Java snippits like this to inline
straight through, even if invokeExact would be megamorphic under
normal circumstances...but I don't think that's the case right now,
right?
I haven't been following 292
On May 15, 2011, at 9:40 AM, Raffaello Giulietti wrote:
I would expect a WrongMethodTypeException to be thrown by
convertArguments in the following snippet, on the ground that String
is neither a wrapper nor a supertype of a wrapper of int, the return
type of mh0.
MethodHandle mh0 =
On May 19, 2011, at 12:53 PM, Charles Oliver Nutter wrote:
I have cases where I want to do some pre and post-call logic around a
target handle. Basically, I need to twiddle some global state before
and after to set up one of our artificial call frames for the target
method to use. How could I
On May 19, 2011, at 11:11 AM, Charles Oliver Nutter wrote:
I've just landed a newer SwitchPoint-based constant caching mechanism.
https://github.com/jruby/jruby/commit/90be178c96053d201ea2a869bda7feddeedcfa10
Cool! That's one of the key use cases for SwitchPoint envisioned by the Expert
On May 19, 2011, at 2:08 PM, Charles Oliver Nutter wrote:
Basically, I want the MH chain to contain all pre/post logic in a
try/finally form wrapped around the eventual direct handle, since
ping-ponging through a generalized piece of code for many different
targets would produce a polymorphic
On May 19, 2011, at 10:06 PM, Charles Oliver Nutter wrote:
I've confimed that the i386 build performs just as poorly. Have not
investigate at inlining or assembly level yet...and it's late, so I'm
going to get some sleep.
It's likely that method handle inlining is failing.
Try
On May 18, 2011, at 11:59 AM, Rémi Forax wrote:
All others are hard because the value of the method handle is not
statically known
i.e the method handle cannot be considered as constant.
It can be optimistically inlined, which is what we do for invokedynamic
instructions.
-- John
http://cr.openjdk.java.net/~jrose/7044892/webrev.00/
7044892: JSR 292: API entry points sometimes throw the wrong exceptions or
doesn't throw the expected one
This is basically a bundle of point fixes having to do with corner cases.
Grouped under this bug:
7038847:
http://cr.openjdk.java.net/~jrose/7032850/webrev.00/
7032850: MethodHandle.invokeGeneric throws unspecified RuntimeException if
parameterized method is called
Summary: Implement invocation corner cases, including correct type conversions
and interface type enforcement.
This is a fix for
http://cr.openjdk.java.net/~jrose/6983728/webrev.00/
6983728: JSR 292 remove argument count limitations
Summary: Remove workarounds and limitations from before 6939861.
Reviewed-by: ?
Remove test exclusions from MethodHandlesTest (key unit test), and extend
argument counts of test cases.
On May 17, 2011, at 1:06 PM, Tom Rodriguez wrote:
MethodTypeForm.java:
-if (c != null) {
+if (c == void.class)
+c = null; // a Void parameter was unwrapped to void; ignore
+if (c != null c != void.class) {
You don't need to both
!= null c != void.class) {
Otherwise looks good as far as I understand.
Vladimir
John Rose wrote:
http://cr.openjdk.java.net/~jrose/7044892/webrev.00/
7044892: JSR 292: API entry points sometimes throw the wrong exceptions or
doesn't throw the expected one
This is basically a bundle
Thanks, Tom. -- John
On May 17, 2011, at 12:59 PM, Tom Rodriguez wrote:
Looks ok.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On May 15, 2011, at 4:05 PM, Charles Oliver Nutter wrote:
I will be patient :)
I just posted the one-line tweak which makes your test case run. I had
intended to put it in with the previous push; sorry.
Please give it a spin!
-- John
___
mlvm-dev
On May 15, 2011, at 5:36 PM, Charles Oliver Nutter wrote:
Can I get a rough guesstimate from the JVM guys how much more overhead
is involved in accessing a never-changed MutableCallSite versus a
ConstantCallSite? I have a few places where I want to use
invokedynamic to lazily initialize some
On May 16, 2011, at 3:34 PM, Charles Oliver Nutter wrote:
So this line builds without coro:
export davinci=$(pwd) guards=buildable testable /coro
Confusing is one word for it, yes :)
Time to apologize...
Just think of '/' as a 7-bit ascii alias for '-' or \u00AC '¬'. (I tried '-'
and
Sorry about the recent instability, Charlie. We are moving to a more robust
system, using ricochet frames to manage argument list transformation, instead
of the previous setup, which was a mix of up to 10 arguments plus varargs
and/or NYI.
I want to turn your bugs around quickly, and can use
I think the problem is that meth-conv-6939861 is disabled with #-testable.
I'll enable it and update the patch from hotspot-comp.
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On May 11, 2011, at 11:41 AM, Christian Thalinger wrote:
On May 11, 2011, at 6:02 PM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7034977/webrev.00
This is the engineering review for the name changes to remove the term
generic from JSR 292.
Looks good. -- Christian
Thanks
On May 12, 2011, at 7:58 AM, Christian Thalinger wrote:
On May 11, 2011, at 6:08 PM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/6939861/webrev.jdk.06/
src/share/classes/java/lang/invoke/AdapterMethodHandle.java:
+if (false spreadArgCount SPREAD_LIMIT
and
test/java/lang/invoke/InvokeGenericTest.java. Is the intent just to clean up
the public API language and worry about any internals later?
Looks good.
tom
On May 11, 2011, at 9:02 AM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7034977/webrev.00
This is the engineering review
Oh, and thanks! :-)
-- John (on my iPhone)
On May 11, 2011, at 10:53 AM, Tom Rodriguez tom.rodrig...@oracle.com wrote:
Looks good
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Thanks, Christian. -- John
On May 11, 2011, at 11:41 AM, Christian Thalinger wrote:
On May 11, 2011, at 6:02 PM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7034977/webrev.00
This is the engineering review for the name changes to remove the term
generic from JSR 292.
Looks
On May 7, 2011, at 8:44 PM, Stephen Bannasch wrote:
cannot use '' with anonymous inner classes
Thanks for the note. Serves me right for going into the dark corners of the
language. -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
On May 5, 2011, at 11:58 PM, Christian Thalinger wrote:
On May 5, 2011, at 1:16 PM, John Rose wrote:
I have finished the last large chunk of JVM work for JDK 7 JSR 292, the
implementation of so-called ricochet frames. Here it is for review:
6939861: JVM should handle more conversion
On Apr 10, 2011, at 12:05 PM, Philip Jenvey wrote:
On Apr 10, 2011, at 12:39 AM, John Rose wrote:
P.S. A general note on scheduling: The official Public Review of the JSR
292 API specification ends on 4/18. Comments are always welcome, but the
door will close for changes soon after
I have finished the last large chunk of JVM work for JDK 7 JSR 292, the
implementation of so-called ricochet frames. Here it is for review:
6939861: JVM should handle more conversion operations
http://cr.openjdk.java.net/~jrose/6939861/webrev.04/
This work started in April 2010 and was
On May 4, 2011, at 5:50 AM, Christian Thalinger wrote:
I don't know how you get over this:
src/share/vm/prims/methodHandles.hpp:487: error: conflicting declaration
‘OopClosure* f’
src/share/vm/prims/methodHandles.hpp:487: error: ‘f’ has a previous
declaration as ‘const frame f’
A
This could be a bug with compressed pointers in MH assembly code. I wonder if
-XX:-UseCompressedOops also fails.
-- John
On Apr 10, 2011, at 9:54 AM, Stephen Bannasch wrote:
These java/lang/invoke tests are failing on my MLVM build today:
InvokeDynamicPrintArgs.java
On Apr 21, 2011, at 9:41 AM, fo...@x9c.fr wrote:
Thanks for the information.
I wondered whether the EG had a hidden set of tests cases...
I think there are two hidden sets, neither of which are (AFAIK) open source:
There is an engineering group in Oracle which is developing JCK tests. IBM's
On Apr 21, 2011, at 12:28 PM, Mark Roos wrote:
If so do I have to do something to enable them?
If not are they in b138?
They look like a good fit for my Smalltalk processes
The coro stuff is probably a good fit for you.
The 292 work is probably stepping on coro's toes in the mlvm
I'm cutting some new code (RicochetFrame logic). Thanks Stephen for the
frequent updates! As you might see from the mercurial log, I fixed several x64
regressions in the new code, but it looks like there is at least one more.
What happens with these flags: -XX:+UnlockDiagnosticVMOptions
In addition to the actual code of the gwt test there is currently a poll-based
test for call site mutation. Eventually this will be replaced by a notification
with zero fast path overhead.
-- John (on my iPhone)
On Apr 11, 2011, at 2:31 PM, Rémi Forax fo...@univ-mlv.fr wrote:
Bottom line,
I want to make a comment on OptimizeMethodHandles here, for those users
(extremely important users!) who build and/or use the JSR 292 features while
they are incubating in the mlvm repository.
As we complete the JDK7 cycle, I'm working on a long-standing problem with the
current implementation
Thanks! -- John
On Apr 8, 2011, at 1:57 AM, Christian Thalinger wrote:
On Apr 8, 2011, at 6:59 AM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7019529/webrev.00
This fixes a small problem in unit testing.
Looks good. -- Christian
http://cr.openjdk.java.net/~jrose/7019529/webrev.00
This fixes a small problem in unit testing.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On Apr 6, 2011, at 3:10 PM, Rémi Forax wrote:
You can also use the dropArguments that takes a List and use
Arrays.asList() followed by subList().
If the desired MethodType is available, you can also use
MethodType.parameterList to get a List of the parameters (at O(1) likely
allocation
Will fix ASAP! -- John
On Apr 4, 2011, at 1:58 PM, Stephen Bannasch wrote:
While working on fixing my mlvm build I just noticed this error in the
console:
+ (cd sources/hotspot; hg qpush -a)
applying bsd.patch
applying meth-7011865.patch
unable to read meth-7011865.patch
now
* asInstance-based interface impl (for single-method interfaces, at least)
I'm not complaining, just pointing that out :)
- Charlie
On Mon, Mar 28, 2011 at 5:37 PM, John Rose john.r.r...@oracle.com wrote:
You may have noticed that the JSR 292 API includes a conversion operator
(called
OpenJDK b135 has JVM support for the new package name java.dyn.invoke, and
therefore the new API names can be used with a b135 JVM plus a suitable
-Xbootclasspath patch. In b136 or b137 the JDK changes will follow, so it will
work out of the box.
Here's my question: Does anybody care if we
You may have noticed that the JSR 292 API includes a conversion operator
(called MethodHandles.asInstance) to allow a method handles to interoperate
with single-method interfaces, such as Runnable. This is a small but (maybe)
useful subset of the SAM conversion which is being defined by
On Mar 28, 2011, at 4:14 PM, Mark Roos wrote:
Where will the anonymousClassLoader end up?
In sun.invoke.anon. (Was sun.dyn.anon.) -- John___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On Mar 28, 2011, at 4:11 PM, Attila Szegedi wrote:
I think I'd use it if it were available.
Also, can you say what you'd use it for, and/or what you'd do without it?
Thanks, -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
On Mar 28, 2011, at 1:06 PM, Jim Laskey wrote:
java.dyn.invoke = java.lang.invoke
On 2011-03-28, at 5:02 PM, John Rose wrote:
OpenJDK b135 has JVM support for the new package name java.dyn.invoke...
D'oh! I'll take that as an indication we want to flush dyn from our symbol
tables
D'oh! I'll take that as an indication we want to flush dyn from our symbol
tables ASAP.
Yes, the new package name is java.lang.invoke.
-- John
On Mar 28, 2011, at 1:06 PM, Jim Laskey wrote:
java.dyn.invoke = java.lang.invoke
On 2011-03-28, at 5:02 PM, John Rose wrote:
OpenJDK b135 has
One bit of review feedback we've gotten is our choice of names for the front
door methods of MethodHandle, invokeExact and invokeGeneric.
There is good consensus for invokeExact as a special case of the more generic
invocation type called invokeGeneric. But the name invokeGeneric is more
On Mar 24, 2011, at 11:24 AM, Stephen Bannasch wrote:
At 2:36 AM -0700 3/23/11, John Rose wrote:
With the renaming going on, the code is changing rapidly. But I think we
are converging. Please let me know what happens with the next build.
Today the build completes fine but I still only
On Mar 24, 2011, at 11:24 AM, Stephen Bannasch wrote:
Today the build completes fine but I still only get one java/lang/invoke test
passing.
FAILED: java/lang/invoke/6987555/Test6987555.java
FAILED: java/lang/invoke/6991596/Test6991596.java
Passed: java/lang/invoke/ClassValueTest.java
On Mar 24, 2011, at 9:01 PM, Stephen Bannasch wrote:
Except for MethodTypeTest, this is the group of failures you might get if
jtreg were using the wrong (out-of-date) javac. That's odd, because I think
jtreg's -jdk: option pulls javac out of the same place as the JVM and JDK
runtime.
http://cr.openjdk.java.net/~jrose/7012648/webrev.jdk.00/
Summary: JDK code for package and class renaming from java.dyn to
java.lang.invoke.
Includes certain other small changes:
- move remaining (miscellaneous) contents of sun.dyn to sun.invoke
- make minor revisions to documentation during
On Mar 23, 2011, at 3:45 AM, Christian Thalinger wrote:
On Mar 23, 2011, at 10:10 AM, John Rose wrote:
http://cr.openjdk.java.net/~jrose/7012648/webrev.jdk.00/
Summary: JDK code for package and class renaming from java.dyn to
java.lang.invoke.
Includes certain other small changes
On Mar 23, 2011, at 12:10 AM, Howard Lovatt wrote:
3. Description of MethodHandles.dropArguments(..., ListClass) and
Description of MethodHandles.dropArguments(..., Class...) interchanged
I can't find this bug; I double-checked the docs and they are correct:
On Mar 21, 2011, at 1:29 AM, Rémi Forax wrote:
Le 21/03/2011 02:54, Stephen Bannasch a écrit :
At 5:49 AM + 3/20/11, john.r.r...@oracle.com wrote:
Changeset: 044bdcf75712
Author:jrose
Date: 2011-03-19 22:49 -0700
URL:
On Mar 21, 2011, at 1:34 AM, Charles Oliver Nutter wrote:
Am I missing something? I thought float to double was fine according
to JLS, and convertArguments says it will do JLS conversions.
Your code is correct. This is a bug in the implementation. It is tracked by
this:
7016250: JSR 292
The standard MH factory methods construct method handles functionally, from the
target backward. This simplifies pure functional implementations, but (as
you found) is kind of hard to read. Constructing them from the caller forward
is often easier to read, since it is a narrative of what
On Mar 21, 2011, at 6:13 PM, Charles Oliver Nutter wrote:
Binder
.from(returns(String.class), arg(a, Integer.class), arg(b,
Float.class), arg(c, String.class)
.reorder(c, c)
Yes, that occurred to me to, at least in this form (which is not very
statically checkable):
Binder
The changed makefiles neglect to add the java/lang/invoke classes to
jre/lib/ct.sym.
Anybody know offhand how to fix this? I had to do this once for java/dyn, but
I've forgotten how.
-- John
On Mar 5, 2011, at 2:45 PM, Stephen Bannasch wrote:
Here's what my build script reports when I
On Mar 7, 2011, at 12:17 AM, John Rose wrote:
Anybody know offhand how to fix this? I had to do this once for java/dyn,
but I've forgotten how.
Never mind: make/docs/CORE_PKGS.gmk
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http
I just pushed some tweaks to the meth-rename patches.
The jtreg tests now pass for me on the built jdk.
The next step is to have someone reproduce this good state of affairs.
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
That looks like an old java is being used. Try manually refreshing the
langtools repo to the latest revision.
Will rebase to bsd-port today.
-- John (on my iPhone)
On Mar 7, 2011, at 6:24 AM, Stephen Bannasch stephen.banna...@deanbrook.org
wrote:
At 1:15 AM -0800 3/7/11, John Rose wrote
On Mar 7, 2011, at 11:34 AM, Stephen Bannasch wrote:
langtools looks up-to-date to me -- after popping the patch queue a manual
pull adds nothing new.
Odd. When you get an error about ([Object)Object not matching some other
signature, it's usually because the compiled call sites of
On Mar 2, 2011, at 9:42 AM, Charles Oliver Nutter wrote:
On Tue, Mar 1, 2011 at 6:42 PM, John Rose john.r.r...@oracle.com wrote:
At least the most important transforms should go through customized code.
These include:
- direct access (no transforms)
- receiver binding (the bindTo
Introduction
The invokedynamic instruction is not designed for use from Java. And yet there
are use cases for syntax support. Java is (among other things) the primary
systems programming language for the JVM. If you are programming a dynamic
language system, you are probably coding a lot of
On Mar 1, 2011, at 11:47 AM, Mark Roos wrote:
Subject: Target build for MLVM class path changes?
Not critical but I would like to plan my tasks around it.
This is a timely question. The short answer is that the Public Review API
should be available in b132 this week in the java.dyn package,
as function
pointers for Java. If this affects your use of 292, please let us know.
Other issues likely to arise have to do with performance disparities between
method handles obtained from MethodHandles.Lookup and the corresponding
bytecoded and reflective operations.
Onward!
-- John Rose
P.S
On Mar 1, 2011, at 5:42 PM, Rémi Forax wrote:
There is also another optimization that should be done.
Once all the optimizations that you have listed will be done,
the code will be as fast (or as slow but I'm optimistic by nature) as
using inner classes.
Let say we have the following
http://cr.openjdk.java.net/~jrose/6839872/jdk-webrev.00/
Summary: move everything into a single package; remove all multi-package
machinery
This is a complex change which consolidates the code into a single package, to
prepare for a clean rename from java.dyn to java.lang.invoke.
This also
Thanks for the build and the report, Stephen!
We dropped a keyword (-testable) from the series file in patches/hotspot/.
I just put it back. Sorry for the mess.
Best wishes,
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
On Feb 23, 2011, at 11:24 AM, Stephen Bannasch wrote:
I'm still getting errors running these tests:
java/dyn/InvokeDynamicPrintArgs.java
That's better. That's that error from January, which should go away when
bsd-port catches up with bug fix 7010180.
On Feb 21, 2011, at 10:55 AM, Ben Evans wrote:
Hi,
I've noticed some oddities with b130 MethodHandles (this is x64 Ubuntu):
private void foo() {
System.out.println(Foo!);
}
The type of MHTest#foo is ()void only if foo is static. Otherwise it is
This is worth a clarification: The only meaningful bootstrap methods will be
static methods and constructors for subclasses of CallSite. I will add a note
to the effect into the javadoc.
Using a virtual method of class C as a BSM means that you expect the first
stacked argument to the BSM to
On Feb 15, 2011, at 6:50 AM, Kirill Shirokov wrote:
- JRuby by Charles Oliver Nutter
- PHP.reboot by Remi Forax
- Smalltalk implementation by Mark Roos (in progress)
I think this recent thread is about an OCaml implementation by Xavier Clerc:
It looks like this regression is due to a version mismatch. The name
invokeVarargs is no longer defined; it was replaced by invokeWithArguments
and has been deprecated for some time (since bug 6981777, circa 10/2010).
I suspect the lambda prototype needs updating. Also, we are in a
http://cr.openjdk.java.net/~jrose/7016261/webrev.00/
This review is for pushing the code change to jdk7/hotspot/hotspot/jdk/.
The corresponding specification change has been reviewed by the 292 EG and via
the Oracle-internal CCC.
-- John
___
mlvm-dev
http://cr.openjdk.java.net/~jrose/7016520/webrev.00/
This review is for pushing the code change to jdk7/hotspot/hotspot/jdk/.
The corresponding specification change has been reviewed by the 292 EG and via
the Oracle-internal CCC.
-- John
___
mlvm-dev
http://cr.openjdk.java.net/~jrose/7014755/webrev.00/
This review is for pushing the code change to jdk7/hotspot/hotspot/jdk/.
The corresponding specification change has been reviewed by the 292 EG and via
the Oracle-internal CCC.
The implementation is missing; it will be supplied later under
On Feb 10, 2011, at 3:46 AM, Rémi Forax wrote:
The main problem is that when you will run it, with a 1.7 VM because
MethodHandle is only available with a 1.7 VM,
the VM will throw a WrongMethodTypeException because as you said the 292
magic will be ignored.
I think it's better for the
On Feb 10, 2011, at 6:57 PM, Attila Szegedi wrote:
BTW there's still this problem with MethodHandles.collectArguments
Thanks for the reminder, Attila. I filed a tracking bug:
7018894 JSR 292 method handle collector transform does not work correctly on
subtypes of Object[]
-- John
Next week the JSR 292 EG will be submitting documents to the JCP to initiate a
formal Public Review. It will be 60 days long, and will (we hope) be quickly
followed by a Proposed Final Draft and spec. finalization.
All this is a required part of the process for formalizing JSR 292 and
On Feb 3, 2011, at 1:17 PM, Charles Oliver Nutter wrote:
I'm ready to update it once MLVM changes have settled down.
Huff, puff... Soon! -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
On Jan 28, 2011, at 7:09 AM, Jim Laskey wrote:
Unfortunate was an incomplete thought.
What I was thinking was, that there was likely no trivial way to treat
exactInvoker(target.type()).bindTo(target) as identity (in bindTo) when
!target.isVarargsCollector(). Likely moot as MH
I'm tardy getting to the main point of this, but here it is:
Thanks, Jim, for finding and diagnosing the bug in the MHs code.
And thanks, Kirill, for pointing out the tautological use of bindTo.
I'll push a fix and a unit test shortly.
I had to change TestFilter.java at one point:
On Jan 31, 2011, at 3:50 PM, Stephen Bannasch wrote:
I'm getting new failures running the dyn tests in mlvm.
Seems like the -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles are
being passed into junit.
Oops, that should work. For some reason, the runtime for MHs now entangles
, Stephen Bannasch wrote:
At 5:35 PM -0800 1/31/11, John Rose wrote:
On Jan 31, 2011, at 3:50 PM, Stephen Bannasch wrote:
I'm getting new failures running the dyn tests in mlvm.
Seems like the -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles
are being passed into junit.
Oops
On Jan 7, 2011, at 1:59 AM, John Rose wrote:
Current drafts of the API (as extracted from the mlvm patch repository) may
always be previewed here:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/
The present draft uses the package name java.dyn. The next draft from the
JSR 292
On Jan 12, 2011, at 9:01 AM, Oscar Rodriguez wrote:
I notice that jsr292 is tagged as 'inactive' (i.e. no progress for 18 mo.)
on the jcp web page: http://jcp.org/en/jsr/detail?id=292
It's the only jsr336 item so tagged: http://jcp.org/en/jsr/detail?id=336
As chair of the EG I noticed
On Jan 12, 2011, at 3:31 AM, Christian Thalinger wrote:
If you want to convert an int to a short, you can use explicitCastArguments.
MethodHandle mh1 = MethodHandles.identity(int.class);
MethodHandle mh2 = MethodHandles.explicitCastArguments(mh1,
MethodType.methodType(short.class,
On Jan 11, 2011, at 7:30 AM, Christian Thalinger wrote:
On Nov 12, 2010, at 2:42 PM, Christian Thalinger wrote:
On Nov 12, 2010, at 2:35 PM, Rémi Forax wrote:
Le 12/11/2010 12:26, Christian Thalinger a écrit :
As I have already said, I'm not expert here but these changes let all
tests of this
On Jan 11, 2011, at 3:26 PM, Stephen Bannasch wrote:
I'm trying to run the four dyn tests in jdk/test/java/dyn for my mlvm build
using jtreg v4.1 and I'm failing 3 out of 4 -- I
assume these tests should pass?
I'd like to run a small subset of tests whenever I have what appears to a
On Jan 11, 2011, at 6:37 PM, Stephen Bannasch wrote:
At 5:48 PM -0800 1/11/11, John Rose wrote:
You can run with jtreg directly like this:
$ jtreg -jdk:$JAVA7X_HOME test/java/dyn/
$ jtreg -jdk:$JAVA7X_HOME test/java/dyn/InvokeDynamicPrintArgs.java
...and so on.
Do the java/dyn
301 - 400 of 706 matches
Mail list logo
