Assembly output from JRuby 'fib'
I prepared this for someone else, but I thought folks here might be interested in it too. This gist contains hotspot x86 (32-bit) assembly output for JRuby's dynopt mode and invokedynamic (on a couple-week-old OS X OpenJDK build). I haven't spent a lot of time investigating. https://gist.github.com/943357 One thing I did notice is that MaxRecursiveInlineLevel appears to be 1 by default normally. I played with bumping it up but performance degraded no matter what combination of flags I used. A related question: what would it take to get the hsdis plugin included with openjdk proper all the time? It would be nice if PrintAssembly worked out of the box on all Java 7 builds. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Target build for MLVM class path changes?
At 11:47 AM -0800 3/1/11, Mark Roos wrote: >Not critical but I would like to plan my tasks around it. > >I am using the late Feb build by Stephen and it is not compatible with b131 >(exception changes ) > >BTW its working great I've built a new version today but all the java/lang/invoke tests are failing because they can't find the package java.lang.invoke: $ jtreg -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -jdk:build/bsd-amd64/j2sdk-image -v:verbose jdk/test/java/lang/invoke/MethodHandlesTest.java details for one of the failed tests ... #section:script_messages --messages:(4/243)-- JDK under test: (build/bsd-amd64/j2sdk-image) openjdk version "1.7.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.7.0-internal-fastdebug-stephen_2011_03_01_16_33-b00) OpenJDK 64-Bit Server VM (build 20.0-b06-fastdebug, mixed mode) #section:compile --messages:(3/304)-- command: compile -source 7 -target 7 -XDallowTransitionalJSR292=no /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/lang/invoke/MethodHandlesTest.java reason: User specified action: run compile -source 7 -target 7 -XDallowTransitionalJSR292=no MethodHandlesTest.java elapsed time (seconds): 3.635 --System.out:(2/74)-- VM option '+UnlockExperimentalVMOptions' VM option '+EnableInvokeDynamic' --System.err:(493/27410)-- /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/lang/invoke/MethodHandlesTest.java:34: package java.lang.invoke does not exist import java.lang.invoke.*; ^ /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/lang/invoke/MethodHandlesTest.java:35: package java.lang.invoke.MethodHandles does not exist import java.lang.invoke.MethodHandles.Lookup; ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JRuby can't compile benchmark. Also package renaming
On 04/06/2011 07:17 PM, Charles Oliver Nutter wrote: > 1. You can pass -d to JRuby to get the debug output from the failure, > or -Xjit.logging.verbose=true. I can take a look at this as soon as I > can update to java.lang.invoke. The compilation error is most probably caused by package rename: warning: could not compile: bench/bench_fib_recursive.rb; full trace follows java.lang.NoClassDefFoundError: java/dyn/CallSite at org.jruby.runtime.invokedynamic.InvokeDynamicSupport.(InvokeDynamicSupport.java:463) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at org.jruby.compiler.impl.StandardASMCompiler.(StandardASMCompiler.java:194) at org.jruby.Ruby.tryCompile(Ruby.java:640) at org.jruby.Ruby.tryCompile(Ruby.java:627) at org.jruby.Ruby.runNormally(Ruby.java:567) at org.jruby.Ruby.runFromMain(Ruby.java:424) at org.jruby.Main.doRunFromMain(Main.java:278) at org.jruby.Main.internalRun(Main.java:198) at org.jruby.Main.run(Main.java:164) at org.jruby.Main.run(Main.java:148) at org.jruby.Main.main(Main.java:128) RuntimeError: could not compile and compile mode is 'force': bench/bench_fib_recursive.rb Thank you! Kirill ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Review Request: Zero JSR 292 support
Hi all, This webrev adds support for JSR 292 to Zero: http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/ Note that is is designed to apply after the fix for 7032458, which is currently under review and can be found here: http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-2/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Review Request: Zero JSR 292 support
On Apr 5, 2011, at 3:46 PM, Gary Benson wrote: > Christian Thalinger wrote: >> On Apr 4, 2011, at 10:34 AM, Gary Benson wrote: >>> John Rose wrote: On Apr 1, 2011, at 7:33 AM, Gary Benson wrote: > 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 >>> >>> Partially, yes, in that it implements invokedynamic and fast_aldc* >>> in the bytecode interpreter. For the sparc or x86 ports you would >>> also need to write the method handle entries and add frame manager >>> support for the call_method_handle message. >> >> How much work would that be? > > I'm not sure. Actually, thinking about it, the method handle entries > are already there (the template and C++ interpreters have the same > ABI, no?) You could check by trying to run the method handles tests. > If that's the case, the only extra bit is adding support for > call_method_handle. There's a potential trap, however, in that the > calls to InterpreterRuntime::resolve_invokedynamic and > InterpreterRuntime::resolve_ldc from BytecodeInterpreter::run enter VM > mode and end up reentering the C++ interpreter. I don't know that the > assembly language ports can handle this. They're certainly written to > avoid it, but that might be simply because BytecodeInterpreter::run > has a huge stack frame and they didn't want too many of those on the > stack. If it is a problem I have some partially written code that > would work around this but once I realised Zero didn't need it I > stopped working on it. I'm not exactly sure how to proceed here. Should we try to implement the missing parts of 6829195 or should we file a separate bug for Zero and push this? -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: latest mlvm failing four java/lang/invoke tests
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
> InvokeGenericTest.java
> JavaDocExamplesTest.java
> MethodHandlesTest.java
>
>
> $ jtreg -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions
> -XX:+EnableInvokeDynamic
> -jdk:build/bsd-amd64/j2sdk-image -v:summary
> jdk/test/java/lang/invoke/Passed: java/lang/invoke/6987555/Test6987555.java
> Passed: java/lang/invoke/6991596/Test6991596.java
> Passed: java/lang/invoke/ClassValueTest.java
> FAILED: java/lang/invoke/InvokeDynamicPrintArgs.java
> FAILED: java/lang/invoke/InvokeGenericTest.java
> FAILED: java/lang/invoke/JavaDocExamplesTest.java
> FAILED: java/lang/invoke/MethodHandlesTest.java
> Passed: java/lang/invoke/MethodTypeTest.java
> Test results: passed: 4; failed: 4
>
> more details:
>
> FAILED: java/lang/invoke/InvokeDynamicPrintArgs.java
>
> #-testresult-
>
> description=file:/Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/lang/invoke/InvokeDynamicPrintArgs.java
> end=Sun Apr 10 12:37:19 EDT 2011
> environment=regtest
> execStatus=Failed. Execution failed: `main' threw exception:
> java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> javatestOS=Darwin 10.7.0 (amd64)
> javatestVersion=4.1.4
> script=com.sun.javatest.regtest.RegressionScript
> sections=script_messages build compile compile build compile main
> start=Sun Apr 10 12:37:15 EDT 2011
> test=java/lang/invoke/InvokeDynamicPrintArgs.java
> work=/Users/stephen/dev/java/src/mlvm/sources/JTwork/java/lang/invoke
>
> #section:main
> --messages:(3/405)--
> command: main indify.Indify --verify-specifier-count=3 --expand-properties
> --classpath ${test.classes} --java
> test.java.lang.invoke.InvokeDynamicPrintArgs --check-output
> reason: User specified action: run main/othervm indify.Indify
> --verify-specifier-count=3 --expand-properties --classpath
> ${test.classes} --java test.java.lang.invoke.InvokeDynamicPrintArgs
> --check-output
> elapsed time (seconds): 0.144
> --System.out:(0/0)--
> --System.err:(41/2600)--
> patching test/java/lang/invoke/InvokeDynamicPrintArgs.main(L)V
> 16:invokestatic 6 INDY_nothing()L;...; 19:invokevirtual 7 => invokedynamic
> 397:InvokeDynamic[0, 395]
> 22:invokestatic 8 INDY_bar()L;...; 28:invokevirtual 10 => invokedynamic
> 404:InvokeDynamic[1, 402]
> 31:invokestatic 11 INDY_bar2()L;...; 39:invokevirtual 10 => invokedynamic
> 406:InvokeDynamic[1, 405]
> 42:invokestatic 13 INDY_baz()L;...; 51:invokevirtual 17 => invokedynamic
> 409:InvokeDynamic[2, 408]
> 54:invokestatic 18 INDY_foo()L;...; 59:invokevirtual 20 => invokedynamic
> 400:InvokeDynamic[0, 399]
> patching test/java/lang/invoke/InvokeDynamicPrintArgs.bsm(LLL)L
> 24:invokestatic 83 MH_printArgs()L => ldc 387:MethodHandle[6, 386]
> patching test/java/lang/invoke/InvokeDynamicPrintArgs.bsm2()L
> 47:invokestatic 83 MH_printArgs()L => ldc 387:MethodHandle[6, 386]
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at indify.Indify.run(Indify.java:130)
> at indify.Indify.main(Indify.java:106)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:613)
> at
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:613)
> at indify.Indify.runApplication(Indify.java:158)
> at indify.Indify.run(Indify.java:127)
> ... 7 more
> Caused by: java.lang.BootstrapMethodError: call site initialization
> exception
> at java.lang.invoke.CallSite.makeSite(CallSite.java:316)
> at
> java.lang.invoke.MethodHandleNatives.makeDynamicCallSite(MethodHandleNatives.java:298)
> at
> test.java.lang.invoke.InvokeDynamicPrintArgs.main(InvokeDynamicPrintArgs.java:50)
> ... 13 more
> Caused by: java.lang.NullPointerException
> at java.lang.invoke.FilterGeneric$F5.invoke_F2(FilterGeneric.java:666)
> at java.lang.invoke.CallSite.makeSite(CallSite.java:288)
> ... 15 more
>
>
> FAILED: java/lang/invoke/InvokeGene
Re: question regarding call sites and garbage collection
On 03/16/2011 11:36 AM, Jochen Theodorou wrote:
> Am 15.03.2011 23:41, schrieb Rémi Forax:
> [...]
>>> If the callsite is inlined, won't
>>> that mean that then we have those types hard referenced as well and that
>>> I cannot do anything against that?
>> A callsite can be inlined more than once.
>> So the reference to the mh can not be dropt
> I ask because I was thinking of a certain artificial case
>
> let us assume I have a class that does this:
>
> Script1:
>
> Object foo(x) {
> return x
> }
> Object bar(x) {
> x.foo(this) // done by call site logic using MethodHandle
> }
>
> Then, if I understood correctly, whatever the class of x is, the class
> will be referenced from this call site and has to live as long as this
> class here does.
The class may be referenced or not, it depends how your compiler
and your inlining cache are implemented.
Let suppose the compiler doesn't do any type inference,
in that case,
x.foo(this)
is translated to
invokedynamic [aBSM] foo(Object,Object)V
so there is no reference to X here.
Now when bar() is called with an instance of X.
Let supoose you use a guardWithTest and store a method handle to foo.
foo is compiled Object foo(Object).
so there is no reference to X here.
But perhaps your test (the GWT test) is a X.isInstance(), then you have
a reference to X
from the callsite (you have inserted X in the test method handle).
Your test can also be a test on the metaclass or an id, in that case
you have no reference to X.
> Now assume I will do the following:
>
> Object lastScript = null
> bigNumber.times {
> MyLoader cl = new CustomClassLoaderOfSomeKind()
> def scriptn = cl.defineClass(...).newInstance()
> scriptn.bar(lastScript==null?scriptn:lastScript)
> lastScript = scriptn
> }
>
> The result, should I have understood correctly, will be, that each
> scriptn will cause the former scriptn (lastScript) to be referenced in a
> way that prefents that from being garbage collected, even though scriptn
> does not reference lastScript directly and there will be no reference to
> the class loader as well. So in theory the last script could be garbage
> collected but the MethodHandles prevent that from happening.
It's not the method handles by itself but how you implement your
inlining cache.
> bye Jochen
Rémi
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: DSL for handle binding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-03-21 20.45, Charles Oliver Nutter wrote:
> On Mon, Mar 21, 2011 at 8:40 PM, John Rose wrote:
>> Yes, that occurred to me to, at least in this form (which is not very
>> statically checkable):
>>
>> Binder
>> .from(String.class, "a", Integer.class, "b", Float.class, "c",
>> String.class)
>> .reorder("c", "c")
>>
>> It's a little harder to imagine unwinding everything to open code when name
>> lookups are involved.
>
> I've been thinking of ways to blunt the cost of the DSL as well. The
> simplest would be saving the Binder before calling "invoke", since
> from there on it can apply to anything with the same types. Another
> might be having Binder emit code for the MethodHandles calls,
> bypassing the normal logic...but of course now we're talking about
> generating code to generate MH binding sequences :)
Actually, I think that would be a very good idea - I see myself having
to do these operations in ASM output quite a lot (I'm already doing it a
bit actually).
Cheers
- --
Ola Bini (http://olabini.com)
Ioke - JRuby - ThoughtWorks
"Yields falsehood when quined" yields falsehood when quined.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNiK3aAAoJEClcdGmEr38MG/8QALTSQmRYBp3B+KNWZ6QT27aF
RJq/fxG65qN852+oZHQkj+DSevl412ci2xlMtSMmN0H3Xt/PZ25ASvFMuownhBzZ
W/wkF2WIGu0A55K7vObltztbrQg1ITcafVpuLIVr/xy68rineGK1vQAs/lnjONqU
KX/s9wODEtAu9nBC7i6bZf0X+m2pipFpu81gaSIB9v6Ef1UqGHuWoNtJ/BGiRrAr
6iu/PEVyqoD2jDLdB92QXe0Xb1wddvnqeurm7pLJTAiFdS124GwCpOqU5v15EHmN
frCyOaHX1d5UHfX0r6PkJBt3Sx3AX7XgkgeqH1Dgf/XG8kdDLQDinG6rbT7zqu3z
VxM6ZJ1y5pe9DtbjK27DCkBSe+XScdgAh2qxRcbL6cgGHvXBZRdYMVd9Ai/vaupd
0PNcob/J+3t3sxnrlFlHI/T9cD4sETEsUIfSH4nVqNRrpBnkfxNIL/tBFZid8zwi
ly0ajV64/amBUeCb6gv8Nzw98o/GayNxwm0znIzgMSDmnO5ropYDQfFK9T9IMj/8
7O9AwV09eui5z0jf77hnM1fcoWGgZm6cbUuZo4JUAyWDlWGr55hS+l1odWJECheT
kjdC68XapXoxcnlgp/iGbVzwkeK7aUfV+Fbqm0qrdcHPZrXGOebNZg25Scw5sqsx
Qd9qhx0SNKGoDonLyQX1
=O5kO
-END PGP SIGNATURE-
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Test cases related to JSR 292
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're right that this is not written anywhere :(
> We should fix that too.
Current javadoc:
* the {@code BootstrapMethods} attribute
* Each {@code CONSTANT_InvokeDynamic} entry contains an index which references
* a bootstrap method specifier; all such specifiers are contained in a
separate array.
* This array is defined by a class attribute named {@code BootstrapMethods}.
This seems to cover it. I added a comment in the structure summary:
// required attribute on any class containing CONSTANT_InvokeDynamic_info:
struct BootstrapMethods_attr {
-- John___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: meth: more on 7016250
Changeset: 94ad41f72ec2 Author:jrose Date: 2011-04-23 01:24 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/94ad41f72ec2 meth: more on 7016250 ! meth-conv-6939861.patch ! meth-ret-7016250.patch ! meth-review-7032323.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: rebase to jdk7-b132 in bsd-port
Changeset: 13266ff20174 Author:jrose Date: 2011-03-19 23:11 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/13266ff20174 rebase to jdk7-b132 in bsd-port + bsd.patch ! meth-doc-7014005.patch - meth-impl-6839872.1-rename.patch - meth-impl-6839872.2-super.patch - meth-impl-6839872.3-moves.patch - meth-impl-6839872.4-vconv.patch - meth-impl-6839872.5-mtform.patch - meth-impl-6839872.6-access.patch - meth-impl-6839872.7-misc.patch ! meth-impl-6839872.patch ! meth-rename-7012648.2.patch ! meth-rename-7012648.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: meth-conv: get buildable (2)
Changeset: 267f82ed2196 Author:jrose Date: 2011-03-22 18:09 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/267f82ed2196 meth-conv: get buildable (2) ! meth-conv-6939861.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
build now succeeds, 5 of 6 java/lang/invoke tests fail
Compilation succeeds but I am getting failures running five of the six java/lang/invoke tests: Passed: java/lang/invoke/ClassValueTest.java FAILED: java/lang/invoke/InvokeDynamicPrintArgs.java FAILED: java/lang/invoke/InvokeGenericTest.java FAILED: java/lang/invoke/JavaDocExamplesTest.java FAILED: java/lang/invoke/MethodHandlesTest.java FAILED: java/lang/invoke/MethodTypeTest.java Test results: passed: 1; failed: 5 These three fail with a java.lang.UnsatisfiedLinkError FAILED: java/lang/invoke/InvokeDynamicPrintArgs.java FAILED: java/lang/invoke/InvokeGenericTest.java FAILED: java/lang/invoke/JavaDocExamplesTest.java command: junit -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.lang.invoke.JavaDocExamplesTest reason: User specified action: run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.lang.invoke.JavaDocExamplesTest elapsed time (seconds): 0.103 --System.out:(0/0)-- --System.err:(24/1603)-- java.lang.UnsatisfiedLinkError: java.lang.invoke.MethodHandleNatives.registerNatives()V at java.lang.invoke.MethodHandleNatives.registerNatives(Native Method) at java.lang.invoke.MethodHandleNatives.(MethodHandleNatives.java:125) at java.lang.invoke.MethodType.makeImpl(MethodType.java:248) at java.lang.invoke.MethodTypeForm.canonicalize(MethodTypeForm.java:388) at java.lang.invoke.MethodTypeForm.findForm(MethodTypeForm.java:350) at java.lang.invoke.MethodType.makeImpl(MethodType.java:244) at java.lang.invoke.MethodType.methodType(MethodType.java:206) at test.java.lang.invoke.JavaDocExamplesTest.(JavaDocExamplesTest.java:81) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at com.sun.javatest.regtest.JUnitAction$JUnitRunner.main(JUnitAction.java:85) at com.sun.javatest.regtest.JUnitAction$JUnitRunner.main(JUnitAction.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:613) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:722) JavaTest Message: Test threw exception: java.lang.UnsatisfiedLinkError: java.lang.invoke.MethodHandleNatives.registerNatives()V These two fail with a different console log: FAILED: java/lang/invoke/MethodHandlesTest.java FAILED: java/lang/invoke/MethodTypeTest.java command: junit -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.lang.invoke.MethodHandlesTest reason: User specified action: run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.lang.invoke.MethodHandlesTest elapsed time (seconds): 0.236 --System.out:(0/0)-- --System.err:(46/6171)-- JavaTest Message: JUnit Failure: testFindStatic(test.java.lang.invoke.MethodHandlesTest): java.lang.invoke.MethodHandleNatives.registerNatives()V JavaTest Message: JUnit Failure: testFindVirtual(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testFindSpecial(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testBind(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testUnreflect(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testUnreflectSpecial(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testUnreflectGetter(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testFindGetter(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testFindStaticGetter(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testUnreflectSetter(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure: testFindSetter(test.java.lang.invoke.MethodHandlesTest): Could not initialize class java.lang.invoke.MethodHandleNatives JavaTest Message: JUnit Failure:
Re: fatal error running MethodHandlesTest
On 04/19/2011 01:12 AM, John Rose wrote: > I'm cutting some new code (RicochetFrame logic). Yai ! > 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:-OptimizeMethodHandles ? > > My latest version of x64 (not yet pushed) does not show this crash, but that > doesn't mean the bug is done. Will push after my taxes are all done. > > -- John Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: fatal error running MethodHandlesTest
At 4:12 PM -0700 4/18/11, John Rose wrote: >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:-OptimizeMethodHandles ? $ jtreg -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -XX:+UnlockDiagnosticVMOptions -XX:-OptimizeMethodHandles-jdk:build/bsd-amd64/j2sdk-image -verbose:all jdk/test/java/lang/invoke/MethodHandlesTest.java Looks like the same segfault: https://gist.github.com/926649 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth-conv: get buildable (2)
Changeset: f2f43ed15b84 Author:jrose Date: 2011-03-22 17:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f2f43ed15b84 meth-conv: get buildable (2) ! meth-conv-6939861.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: review request (L): 7012648/JDK: move JSR 292 to package java.lang.invoke and adjust names
Yay! On Wed, Mar 23, 2011 at 4: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: > - move remaining (miscellaneous) contents of sun.dyn to sun.invoke > - make minor revisions to documentation during Public Review > - remove the out-of-scope term "SAM type" from documentation and code > - delete unused methods and classes > - make minor (API-invisible) code cleanups > > The non-renaming changes may be viewed separately here: > http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-rename-7012648.2.patch > > This change set is for the JDK repository, specifically: > http://hg.openjdk.java.net/jdk7/hotspot/jdk > > A previous coordinated change set for the JVM, also marked with bug 7012648, > is about to be promoted (jdk7-b135). > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: change invokeGeneric to invoke in MethodHandle?
I assume this means invokeGeneric is firmly established in the specification. I would agree with "invoke" as well. On Sun, Mar 27, 2011 at 1:27 AM, Jeroen Frijters wrote: > +1 invoke makes sense. > >> -Original Message- >> From: mlvm-dev-boun...@openjdk.java.net [mailto:mlvm-dev- >> boun...@openjdk.java.net] On Behalf Of John Rose >> Sent: Saturday, March 26, 2011 10:08 PM >> To: Da Vinci Machine Project >> Subject: change invokeGeneric to invoke in MethodHandle? >> >> 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 problematic. >> >> First, it seems to mention "generics", even though it has nothing to do >> with Java generic types (except that it can dynamically supply the casts >> that the erasure technique sometimes requires). >> >> Second, the term "generic" doesn't have any other meaning, other than >> "this is somehow more general than the exact version". >> >> There are two alternatives to "generic". One is to find the word or >> phase that we should have picked instead of "generic", such as >> "polymorphic" or "withConversions". The other is to drop the word, and >> use just "invoke". >> >> Some of us on the EG (including me) are inclined to go with plain >> "invoke". Does anyone see a problem with this? >> >> Benefits: >> - makes typical code examples (documents, slides, pedagogy) easier to >> write and read >> - strengthens the analogy with JVM terminology, JLS terminology, >> reflection, etc. >> - "exact" functions as an extra type-match requirement/assertion >> (asymmetry with "invokeExact" is not a problem) >> - the terms nest nicely: one can speak of "method handle invocation" >> and when needed of "exact invocation" >> >> Comments? >> >> -- John >> >> P.S. Some background, as a reminder: >> >> http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-pr/ (OpenJDK >> doc snapshot for Public Review) >> >> The difference between the two "front doors" is that "invokeExact" >> requires the same descriptor matching that the native JVM invoke >> instructions require, while "invokeGeneric" is a strict superset, >> allowing certain simple conversions on arguments and return values. >> >> The two-door model here allows implementors to choose native JVM strict >> typing (invokeExact) or a flexible simulation of argument conversions, >> approximately as allowed in the Java language. The invokeExact call is >> useful for systems that do not want accidental introduction of runtime >> argument transformations, while the invokeGeneric call is probably most >> useful for end users. (It also has benefits for building some kinds of >> method handle transformations.) >> >> There is actually a third "door" which is a garden-variety "varargs" >> method MethodHandle.invokeWithArguments. It is supposed to have a long >> name, to hint that it is not your first choice, because it is guaranteed >> to do all possible boxing steps. Indeed, it is more closely akin to >> java.lang.reflect.Method.invoke than MethodHandle.invokeGeneric, but for >> that reason it is *not* the primary entry point for method handle >> invocation. The main use for it is to apply a method handle to a pre- >> existing array of arguments. >> ___ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Test cases related to JSR 292
Le 22 avr. 2011 à 16:42, Rémi Forax a écrit : > >>> This is a possibility, hoping that the entry ticket to the ASM API is not >>> to high. >>> >>> While developing the code to read/write a JDK7 class file, I noticed what I >>> think >>> is a typo on the >>> "http://download.java.net/jdk7/docs/api/java/lang/invoke/package-summary.html"; >>> page. The line: >>> u1 reference_kind; // 1..8 (one of REF_invokeVirtual, etc.) >>> should probably be: >>> u1 reference_kind; // 1..9 (one of REF_invokeVirtual, etc.) >>> unless interface methods are explicitly forbidden. In the latter case, what >>> is >>> the motive? >> Sorry for the noise, but I have another question regarding the >> aforementioned URL >> that I use as a specification for JSR 292. It is not clear which elements >> can embed >> a "BootstrapMethods" attribute, possible candidates being, at first sight: >> - a "Code" attribute; >> - a method; >> - a class. >> >> 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're right that this is not written anywhere :( > We should fix that too. Thanks for the clarification. This is what I figured out from an ancient hg commit, but my intuition was conflicting with this fact... Can you elaborate on the rationale behind this EG choice? The only advantage I can think of is data sharing, but it seems more or less done by the constant pool. I would have placed "BootstrapMethods" at the same level as "LineNumberTable" or "StackMapTable", based on some kind of locality property. Xavier ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Request for test change
Hi all, The tests in jdk/test/java/dyn have a checkImplementedPlatform() method which disables the tests on platforms other than x86 and Sparc. This webrev adds the zero-assembler port to the list of supported platforms: http://cr.openjdk.java.net/~gbenson/zero-jsr292-tests/ Would it be possible to get this added please? Thanks, Gary -- http://gbenson.net/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Review Request: Zero JSR 292 support
On Apr 1, 2011, at 4:33 PM, Gary Benson wrote: > Hi all, > > This webrev adds support for JSR 292 to Zero: > > http://cr.openjdk.java.net/~gbenson/zero-jsr292-01/ hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp: +// NB the x86 code for this (in methodHandles_x86.cpp, search for +// "genericInvoker") is really really odd. I'm hoping it's trying +// to accomodate odd VM/class library combinations I can ignore. Do you mean the code around sorry_no_invoke_generic? hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: + assert(false, "Should have thrown incompatible class change exception"); I'd use ShouldNotReachHere instead. I have to say that I don't know very much about the C++ interpreter or Zero but the code looks good. Most important is that the MethodHandlesTest passes. -- Christian > > Note that is is designed to apply after the fix for 7032458, > which is currently under review and can be found here: > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-2/ > > I don't have a bug id for this. > > Cheers, > Gary ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: new Mac OS X mlvm build: 2011_04_04
On 04/05/2011 09:41 PM, Ola Bini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2011-04-05 09.07, Rémi Forax wrote: >> Basically in constant() bindTo(x) should be replaced by >> insertArguments(0, x) >> Because bindTo requires that the first argument is an object. >> Here it's a boolean. > So basically you're saying that this line: > return identity(type).bindTo(w.convert(value, type)); > has to become > return insertArguments(identity(type), 0, w.convert(value, > type)); > > Correct? yes ! The other answer is to not bridle bindTo() to only use object. Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
coro patch not applying cleanly
The coro patch is not applying cleanly anymore: applying coro.patch patching file src/share/vm/interpreter/interpreterRuntime.cpp Hunk #1 FAILED at 893 1 out of 1 hunks FAILED -- saving rejects to file src/share/vm/interpreter/interpreterRuntime.cpp.rej patching file src/share/vm/prims/nativeLookup.cpp Hunk #2 FAILED at 123 1 out of 2 hunks FAILED -- saving rejects to file src/share/vm/prims/nativeLookup.cpp.rej patching file src/share/vm/utilities/debug.hpp Hunk #1 succeeded at 177 with fuzz 2 (offset 14 lines). patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh coro.patch *** Exit status 2. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: 4 new changesets
Changeset: 119e23ae6565 Author:jrose Date: 2011-04-07 16:25 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/119e23ae6565 remove stray whitespace ! indy-notrans-6981791.patch ! meth-impl-6839872.patch Changeset: b3dd77786318 Author:jrose Date: 2011-04-07 20:54 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b3dd77786318 remove patches for closed bugs - indy-cpool-6930553.patch - meth-con-7024561.patch ! meth-err-7012087.patch ! series Changeset: 10c69d859aba Author:jrose Date: 2011-04-07 20:55 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/10c69d859aba meth: fix method handle verification bug ! meth-ver-6987991.patch Changeset: 9ef7acb70397 Author:jrose Date: 2011-04-07 20:58 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9ef7acb70397 meth-conv: refresh patch ! meth-conv-6939861.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: field type is not final in MethodHandle
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 "final" off of methods in MethodHandle in order to allow implementors the option of specializing behavior. (Exception: The signature-polymorphic methods, which the JVM treats specially, are marked as final natives. If implementors want to get some benefit by overriding these, they will have to cooperate with the JVM magically anyway.) Is there a problem with this? -- John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Review Request: Zero JSR 292 support
On Apr 5, 2011, at 2:49 PM, Christian Thalinger wrote: >>> Does this code pass the jtreg tests in jdk/test/java/lang/invoke/ ? >> >> It passed their previous incarnation in jdk/test/java/dyn, with >> this webrev applied to stop the tests disabling themselves: >> >> http://cr.openjdk.java.net/~gbenson/zero-jsr292-tests/ > > John, can you add that code with one of your changes? John, not sure you saw that email. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: 292 Rocks, Core Smalltalk running thanks to all
Ok, I'll pull together a self contained app to try mark From: Christian Thalinger To: Da Vinci Machine Project Date: 04/12/2011 12:54 AM Subject: Re: 292 Rocks, Core Smalltalk running thanks to all Sent by: mlvm-dev-boun...@openjdk.java.net On Apr 11, 2011, at 8:01 PM, Mark Roos wrote: Hi Christian, I've always liked your enthusiasm So far we are running on OSX and the latest win7 build. both work fine. Now that we have the core running we need to move to java.lang.invoke ( which should be trivial). What is it you like to look at? Once we make the move I could package up an example for you to try Not sure yet. I guess you have a couple of regression tests or benchmarks? I would just run them on different systems with different compilers to see if there is a problem somewhere. Since there are not many projects out there that already use JSR 292 (JRuby and phpreboot are the only real users that I know of, but maybe I missed something), the code path coverage is low and almost every new project finds a bug (or more). I want people to have something that works with the projects out there when JDK 7 ships. -- Christian___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: 292 Rocks, Core Smalltalk running thanks to all
On Apr 12, 2011, at 2:56 PM, Ola Bini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > >> Since there are not many projects out there that already use JSR 292 >> (JRuby and phpreboot are the only real users that I know of, but maybe I >> missed something), the code path coverage is low and almost every new >> project finds a bug (or more). > Christian, if you want to see a few more code paths exercised, you can > also use Seph. The test suite does some things with SwitchPoints etc, > that I'm not sure anyone else uses. It's under heavy development though, > and I haven't tried it on any other machine than mine: > > https://github.com/seph-lang/seph > > it should be a simple matter of running ant though. Awesome, thanks! It built but I got errors: [junit] Testsuite: seph.lang.code.BasicSanityTest [junit] Tests run: 40, Failures: 0, Errors: 40, Time elapsed: 0.121 sec Ahh, I see the problem: [junit] Testcase: printing_accumulator_values(seph.lang.code.BasicSanityTest): Caused an ERROR [junit] null [junit] java.lang.ExceptionInInitializerError [junit] at seph.lang.Runtime.(Runtime.java:76) [junit] at seph.lang.code.BasicSanityTest.printing_accumulator_values(BasicSanityTest.java:175) [junit] Caused by: java.lang.IllegalArgumentException: no leading reference parameter: true [junit] at java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:81) [junit] at java.lang.invoke.MethodHandle.bindTo(MethodHandle.java:1001) [junit] at java.lang.invoke.MethodHandles.constant(MethodHandles.java:1625) [junit] at java.lang.invoke.SwitchPoint.(SwitchPoint.java:113) This is covered by: 7035513: JSR 292: MHs.constant() doesn't accept primitives -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Test cases related to JSR 292
Le 22 avr. 2011 à 19:29, John Rose a écrit :
> 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're right that this is not written anywhere :(
>> We should fix that too.
>
> Current javadoc:
>
> * the {@code BootstrapMethods} attribute
> * Each {@code CONSTANT_InvokeDynamic} entry contains an index which
> references
> * a bootstrap method specifier; all such specifiers are contained in a
> separate array.
> * This array is defined by a class attribute named {@code BootstrapMethods}.
>
> This seems to cover it.
You are right; I did not read carefully.
Sorry for the noise.
Regards,
Xavier
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth-conv: correct oops_do
Changeset: 762a9f1e693f Author:jrose Date: 2011-04-21 01:57 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/762a9f1e693f meth-conv: correct oops_do ! meth-conv-6939861.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
