Thanks Rémi
I tried to put just the offending class on the boot path but that was not
enough.
The entire app worked so I guess the solution is somewhere in between
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/ma
>From Jeroen
I took the liberty of downloading it as well, to test on IKVM.NET
:-)
Glad it helped
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
I put my jar on the boot class and the problem goes away on OSX version.
Thanks
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On 08/26/2011 09:24 PM, Mark Roos wrote:
Thanks for the quick look. (glad to see it ran for you)
By the 'runtime' to add to the bootclass path do you mean rt.jar or my
runtime (RtalkTest.jar)?
Your runtime. rt.jar is already in the bootstrap path.
mark
cheers,
Rémi
_
Thanks for the quick look. (glad to see it ran for you)
By the 'runtime' to add to the bootclass path do you mean rt.jar or my
runtime (RtalkTest.jar)?
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinf
I can confirm the NCDFE. This could be a duplicate of:
7055941: JSR 292 method handle invocation causes excessive deoptimization for
types not on boot class path
The workaround is to put the runtime on the boot class path.
I also can confirm that the second run of Hanoi is slower with JDK 7.
Mark Roos wrote:
> The error I see is that at random times when I am executing Smalltalk on
> jvm I get occasional a ClassDefNotFound during an InvokeExact. Usually
> when I am doing a demo. After lots of trying I have a test which fails
> every time for me. When it fails the stack depth varies
