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 P
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.
Best wishes,
-- John
On Mar 20, 2011, at 6:54 PM, Stephen Bannasch wrote:
> At 5:49 AM + 3/20/11, john.r.r...@oracle.com wrote:
>> Changeset: 044bd
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.
>>
On Mar 23, 2011, at 12:10 AM, Howard Lovatt wrote:
>>> 3. Description of MethodHandles.dropArguments(..., List) and
>>> Description of MethodHandles.dropArguments(..., Class...) interchanged
>>
>> I can't find this bug; I double-checked the docs and they are correct:
>>
>> http://cr.openjdk.java
verbs
from imperative to indicative. This conforms with relevant javadoc style
guidelines:
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#styleguide
-- John
On Mar 23, 2011, at 8:30 PM, John Rose wrote:
> On Mar 23, 2011, at 3:45 AM, Christian Thalinger wrote:
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 compl
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.jav
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
>> runti
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
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 Project
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.
>
> On an unrelated sidenote, I totally read that as "who needs assistance"
:-) If we keep it, we are likely to give it a more distinctive name, like
"asInterfaceInstance". Also (or instead), it may
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
http://mail.op
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 w
; As an aside, I think it is great that you ask these questions and
> consider the responses from the wider community.
I'm glad!
-- John
> Cheers,
>
> -- Howard.
>
> On 29 March 2011 09:37, John Rose wrote:
>> You may have noticed that the JSR 292 API includes a
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
That little phrase "after appropriate testing" conceals weeks of testing making
sure there are no regressions.
Thanks for shepherding this, Christian!
-- John
On Mar 31, 2011, at 2:40 PM, Rémi Forax wrote:
> Champagne !
>
> Rémi
>
>
> Original Message
> Subject: hg: j
On Apr 1, 2011, at 7:33 AM, Gary Benson wrote:
> Hi all,
>
> This webrev adds support for JSR 292 to Zero:
>
> http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/
Most impressive! I think this matches the following previously filed bug:
6829195 JSR 292 needs to support the C++ interpreter
D
user bytecode
> * JRuby's own bytecode-based interface impl
> * 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
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
On Apr 6, 2011, at 9:35 AM, Charles Oliver Nutter wrote:
> And the flag does not seem to work either :(
>
> [apt] Warning: The flag +AllowTransitionalJSR292 has been EOL'd as of
> 7.0 and will be ignored
There might be ways you could combine a previous build with an even older
meth.jar (contain
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 cost
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
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.
>
>
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
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 wrote:
>> Bottom line, though is that t
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
-XX
Thanks. Will fix by making it non-public. -- John
On Apr 20, 2011, at 1:10 PM, Rémi Forax wrote:
> The class java.lang.invoke.MemberName.Factory is public but should not.
>
> It's not a big issue because the compiler will reject any attempt to access
> to this class because java.lang.invoke.Me
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.
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
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
> InvokeGenericT
On Apr 22, 2011, at 7:42 AM, Rémi Forax wrote:
>>
>> My first move would be to regard this attribute as reserved to a "Code"
>> attribute,
>> but it seems that data sharing would be increased by putting it a the class
>> level.
>
> The BootstrapMethods attribute is a class attribute.
> And you'
On Apr 7, 2011, at 12:11 PM, Rémi Forax wrote:
> Hi gang, hi John,
> I've just found that MethodHandle.type is not declared final.
Hi Remi.
Since there will be no way for users to specify their own subclasses or access
implementation subclasses, I don't think this matters. We are leaving "fin
On Apr 29, 2011, at 6:19 AM, Rémi Forax wrote:
> ricochet rulez ?
>
> Rémi
Haz ricochet.
Here are some comments on this stuff.
Curry's original BCKW system of combinators
(http://en.wikipedia.org/wiki/B,C,K,W_system) is similar to the MH api.
B(f,g) = λ x . f(g(x)) // MHs.filterArguments(f
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
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 wil
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 partia
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:
>>
>
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
http:
As previously discussed (late March of this year), the JSR 292 draft spec. uses
the word "generic" in a different sense from the Java language. This was a
mistake, and we are going to back off from that term. Instead of saying
mh.invokeGeneric(x,y) the spelling will be simply mh.invoke(x,y).
On May 11, 2011, at 7:25 AM, Charles Oliver Nutter wrote:
> How would I go about debugging a
> failure in the chain that happens some time after I've wired it up and
> bound it to a call site?
Everything after the "method__0$RUBY$fib_ruby" frame (invoke_L5) is always
going to be opaque. If your
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.
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo
http://cr.openjdk.java.net/~jrose/6939861/webrev.jdk.06/
This is the JDK code which works on top of ricochet frames.
These frames were put into the JVM last week, also under bug 6939861 in the
hotspot repository.
It fixes a large number of bugs pertaining to argument conversions, argument
coun
ng/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
>&g
Oh, and thanks! :-)
-- John (on my iPhone)
On May 11, 2011, at 10:53 AM, Tom Rodriguez 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
>
Thanks very much.
-- John (on my iPhone)
On May 11, 2011, at 9:16 PM, Tom Rodriguez wrote:
> I've reviewed this as well as I could and it all looks reasonable.
>
> tom
>
> On May 11, 2011, at 9:08 AM, John Rose wrote:
>
>> http://cr.openjdk.java.net
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&q
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 &&
This is a huge milestone. Thanks, Charlie, for all of your incredibly
constructive input to JSR 292! -- John
On Apr 27, 2011, at 10:34 AM, Charles Oliver Nutter wrote:
> FYI I have finally pushed my indy updates to JRuby master for eventual
> release in JRuby 1.7. I have also removed the indy_
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 s
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 so
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
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: MethodType.fromMethodDescri
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 invoke[
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.
Remove
Sorry folks. Stubborn rt.jar classes won't go quietly into that good night.
Marked the new patch -buildable. -- John
On May 17, 2011, at 10:58 AM, Charles Oliver Nutter wrote:
> Confirmed here too. And since it wiped out my previous copy I'm dead
> in the water at the moment :(
>
> - Charlie
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
> +if (c != 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
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 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
___
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 coul
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 polymorp
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 -XX:+UnlockD
Yes we do agree. And thank you for framing up the question so clearly.
-- John (on my iPhone)
On May 20, 2011, at 4:31 PM, Charles Oliver Nutter wrote:
> do we agree that an invokedynamic bound to a GWT plus some intermediate
> adapter handles ending in a direct handle should inline as well
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
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 th
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 followi
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 you
On May 23, 2011, at 7:33 PM, Ola Bini wrote:
> Have you seen any reason why that happens?
There are some known problems (crashers even) with method handle compilation.
The permuteArguments transform has a bug when you mix long/doubles and other
argument types.
I have a crasher in one of my "di
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
This is the last major bundle of changes for JDK 7.
http://cr.openjdk.java.net/~jrose/7032323/webrev.00/
(Note: This is an engineering code review. The associated API documents are
also under review and are about to be finalized by the Expert Group. Here is a
recent version: http://cr.openj
On May 25, 2011, at 3:20 AM, Ola Bini wrote:
> Just to clarify, my builds are against the current patchset in the MLVM
> repository, so that might explain why you're not seeing these problems.
Good news: The jdk7 repository just integrated a bunch of critical 292 fixes.
I hope the bsd-port can
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:
http://cr.openjdk.
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
htt
On May 25, 2011, at 11:04 PM, Charles Oliver Nutter wrote:
> I don't say it's not clever. It's just not something anyone is
> typically going to figure out on their own. There will be constant
> questions "if I can invalidate a SwitchPoint, why can't I ask if it
> has been invalidated?"
You are r
= K_true);
}
> tom
>
> On May 25, 2011, at 3:30 AM, John Rose wrote:
>
>> This is the last major bundle of changes for JDK 7.
>> http://cr.openjdk.java.net/~jrose/7032323/webrev.00/
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On May 26, 2011, at 12:15 AM, Charles Oliver Nutter wrote:
> It is definitely frustrating to see that perf has degraded so much the
> past couple weeks and still not be there with the reverted code.
I second that.
I did some more cherry-picking this evening and the mlvm patch queue is now
close
On May 26, 2011, at 1:42 AM, Christian Thalinger wrote:
> Using Tom's new code doesn't make a difference since I think the meth.jar
> from John includes the reverted GWT code.
I just added a hook to test whether the GWT change matters or not. Choose
either flag setting:
java -Djava.lang.invo
On May 26, 2011, at 2:12 AM, Ola Bini wrote:
> Hey John,
>
> Something in the patch queue fails to apply cleanly:
That was quick! I noticed that when I spun the meth.jar. Fixed! -- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.
On May 26, 2011, at 3:02 AM, Rémi Forax wrote:
>> ...which pretty much
>> describes all concurrently mutable state, doesn't it? ;)
>
> You're right :)
>
>> - Charlie
>
> Rémi
Caught me. :-) That didn't take long. -- John
___
mlvm-dev mailing list
Invalidity is stable because it is permanent.
-- John (on my iPhone)
On May 26, 2011, at 12:10 PM, "Y. S. Ramakrishna"
wrote:
> John, you state that validity is not a stable property.
> Is invalidity a stable property, or not even that is.
>
___
m
On May 26, 2011, at 1:21 PM, Charles Oliver Nutter wrote:
> isInvalid seems a bit double-negativy to me.
That's my hesitation. Consider the use case:
void maybeCleanUpMess(SwitchPoint sp) {
if (!mysp.isInvalid()) return;
... // do cleanup after invalidation
}
It reads better as:
On May 26, 2011, at 2:43 PM, Charles Oliver Nutter wrote:
> Hmm, I'll look into it. I used the amd64 build from the hsdis project
I posted the bsd/amd64 libdis when I was desperate for something that would at
least link and partially decode instructions. But that hsdis binary doesn't
really kn
On May 26, 2011, at 3:45 PM, Charles Oliver Nutter wrote:
> Ahh...well is there another binary you can point me at? Otherwise,
> I'll just do i386 asm for now.
I tagged it. It's broken in the sense that it's a brutal 64-bit build of code
designed only for 32-bit disassembly.
I suggest doing at
On May 26, 2011, at 10:11 AM, Tom Rodriguez wrote:
> isValid looks fine.
Thanks Tom. I also corrected the javadoc, added a demo of isValid and copied
the javadoc example into the unit tests.
-- John
diff --git a/src/share/classes/java/lang/invoke/SwitchPoint.java
b/src/share/classes/java/lan
On May 26, 2011, at 4:53 PM, Charles Oliver Nutter wrote:
> On Thu, May 26, 2011 at 5:20 AM, Rémi Forax wrote:
>> As far as I know there is no specific optimization of SwitchPoint
>> i.e there is still a volatile read in the middle of the pattern.
>
> If that's true I'm not sure how this is bett
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 mailin
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 w
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 arra
On May 26, 2011, at 11:38 PM, Ola Bini wrote:
> It seems there is still a difference in how asType MHs work between what
> is in current JDK7 repo, and what you get from building bsdport with
> mlvm patches. Specifically, when running things with bsdport/mlvm they
> work. When running on JDK7 (bui
On May 27, 2011, at 12:11 AM, Ola Bini wrote:
> I ran the compile against what's in b144, but directly from the JDK7 repo
>
> On 2011-05-27 12.26, John Rose wrote:
>> On May 26, 2011, at 11:38 PM, Ola Bini wrote:
>>
>>> Caused by: java.lang.IllegalArgumentE
On May 27, 2011, at 12:24 AM, Ola Bini wrote:
> But then it crashes at the same place.
Excellent!
So this works in b144 but not in mlvm?
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On May 27, 2011, at 12:26 AM, Ola Bini wrote:
> type() is just a call site type, so that will be the SephObject,SThread etc.
Good. So what's the code that creates the target (not the fallback)? It looks
like it has its types denatured to Object. -- John
__
1 - 100 of 1108 matches
Mail list logo
