Le 06/08/2009 02:40, Charles Oliver Nutter a écrit :
On Wed, Aug 5, 2009 at 7:30 PM, Rémi Foraxfo...@univ-mlv.fr wrote:
I have seen some small rooms of improvement in the JRuby code
(apart from replacing DynamicMethod by MethodHandle which is
what must be done but which is also in my
So it looks like something is causing the iteration over the oops in
an interpreter frame on a Java thread stack to fail, and this
happens prior to a GC (so GC is likely not screwing up here,
but rather perhaps the interpreter).
With those very general remarks, it's over to the MLVM cognoscenti
And I am standing by to push any other gdb buttons necessary to help
investigate :) Given a couple months I might be able to dig into Hotspot
internals myself, but alas...
On Wed, Aug 5, 2009 at 1:20 AM, Y. Srinivas Ramakrishna
y.s.ramakris...@sun.com wrote:
So it looks like something is
Le 05/08/2009 03:17, Charles Oliver Nutter a écrit :
On Tue, Aug 4, 2009 at 8:16 PM, Rémi Foraxfo...@univ-mlv.fr wrote:
- remove the assertion that invokedynamic can only appear
in class 1.7 compatible (version 51.0) class,
currently your classes are not compiled with version 51.
On Wed, Aug 5, 2009 at 10:43 AM, Rémi Foraxfo...@univ-mlv.fr wrote:
Ok, the backport is now able to correctly optimize your code
(a stupid instead of ||)
and i'm happy to say that the backport now performs better.
Oh yes, these numbers are much better! This renews my resolve to have
a look at
Thanks! That's a variant of this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=689
On Aug 2, 2009, at 2:42 PM, Attila Szegedi wrote:
Note how there's no
semicolon after Ljava/lang/String
___
mlvm-dev mailing list
On Aug 4, 2009, at 5:58 PM, Charles Oliver Nutter wrote:
I'm confident in the Hotspot guys :)
Thanks; we are working hard to justify that confidence. Christian has
begun inlining more complex chains such as lambda (long x) = { x +
x } :
I think Christian is asleep right now, so I'll steal his thunder and
give a mini-update: He's almost certainly found the key crasher. It
was a bit of known-kludgey code (mine) we put into the stack walker.
It's the logic the recognizes return-points after MH.invoke calls.
Now we have
On Wed, Aug 5, 2009 at 7:30 PM, Rémi Foraxfo...@univ-mlv.fr wrote:
I have seen some small rooms of improvement in the JRuby code
(apart from replacing DynamicMethod by MethodHandle which is
what must be done but which is also in my opinion a more than one week job
:)
Nah, it's a day at
Christian Thalinger wrote:
Still building the newly checked out version...
Finally I can reproduce the crashes. Either it's related to debug vs.
product build or the additional patches applied. Still investigating...
-- Christian
___
mlvm-dev
Christian Thalinger wrote:
Christian Thalinger wrote:
Still building the newly checked out version...
Finally I can reproduce the crashes. Either it's related to debug vs.
product build or the additional patches applied. Still investigating...
Oh no! It's so obvious :-/
Christian Thalinger wrote:
Christian Thalinger wrote:
Christian Thalinger wrote:
Still building the newly checked out version...
Finally I can reproduce the crashes. Either it's related to debug vs.
product build or the additional patches applied. Still investigating...
Oh no! It's so
Hm... Which doesn't really explain why did the fib benchmark run for
me with my last build then, does it? Puzzling...
Attila.
On 2009.08.04., at 14:03, Christian Thalinger wrote:
Christian Thalinger wrote:
Christian Thalinger wrote:
Still building the newly checked out version...
Finally
On Mon, Aug 3, 2009 at 10:25 AM, Rémi Foraxfo...@univ-mlv.fr wrote:
Hi Charlie,
I manage to be able to use the backport with you're code
but you really a rogue, you load your classes with the bootstrap classpath
(I suppose you bypass the verifier to start faster)
and guess what, by default,
It's great that you got it running...I will try with the updated
-testing on the compiler patch and see what I can see here.
Attila: Can you show the command line you're using to run fib in
JRuby? And can you try running JRuby with --bytecode and see if it's
actually emitting INVOKEDYNAMIC?
On
On 2009.08.04., at 20:02, Charles Oliver Nutter wrote:
It's great that you got it running...I will try with the updated
-testing on the compiler patch and see what I can see here.
Attila: Can you show the command line you're using to run fib in
JRuby?
Wait, I got it - I downloaded the
Okay, uploading a new build. URL is
http://files.getdropbox.com/u/362958/mlvm/mlvm-macosx-i586-20090804.tgz
but as usual give it two hours to actually get uploaded...
I can now confirm that it indeed does work with jruby-1.4.0dev that
indeed emits invokedynamic.
The only catch is, it's
Le 04/08/2009 20:01, Charles Oliver Nutter a écrit :
On Mon, Aug 3, 2009 at 10:25 AM, Rémi Foraxfo...@univ-mlv.fr wrote:
Hi Charlie,
I manage to be able to use the backport with you're code
but you really a rogue, you load your classes with the bootstrap classpath
(I suppose you bypass the
I can't seem to catch a break. My local build and Attila's build still
both crash for me. There's got to be something about my environment
that's different, eh?
As before, interpreter runs fine. Anything that runs long enough to
jit seems to crash. I've attached the latest log.
On Tue, Aug 4,
On Tue, Aug 4, 2009 at 8:16 PM, Rémi Foraxfo...@univ-mlv.fr wrote:
- remove the assertion that invokedynamic can only appear
in class 1.7 compatible (version 51.0) class,
currently your classes are not compiled with version 51.
BTW, John, It should not work with the JSR 292 RI too ?
Here's the output with the verify flags on:
~/projects/jruby ➔ jruby -J-XX:+UnlockDiagnosticVMOptions
-J-XX:+VerifyBeforeGC -J-XX:+VerifyAfterGC
-J-Djruby.compile.invokedynamic -J-XX:+EnableInvokeDynamic
bench/bench_fib_recursive.rb 100
[Verifying threads permgen tenured generation def new
The ShowMessageBox option also gave me the option of launching gdb.
I'm not a gdb expert, but bt produced this:
(gdb) bt
#0 0x96ebf3ae in __semwait_signal ()
#1 0x96f04398 in pthread_join$UNIX2003 ()
#2 0x668b in ContinueInNewThread0 ()
#3 0x440e in JLI_Launch ()
#4 0xd388 in
Ok, found it...there are 9 threads active:
(gdb) info threads
9 process 43094 thread 0x2903 0x96ebf3ae in __semwait_signal ()
8 process 43094 thread 0x2803 0x96ebf3ae in __semwait_signal ()
7 process 43094 thread 0x2703 0x96ebf3ae in __semwait_signal ()
6 process 43094 thread 0x2603
Charles Oliver Nutter wrote:
Ok, finally circled back around to testing things again. With Attila's
build, I'm still getting crashes, but more seems to work.
I've attached the dump from the crash. To reproduce:
1. grab and unpack a JRuby nightly from
I just updated my GIT repository,
Charles Oliver Nutter wrote:
Ok, finally circled back around to testing things again. With Attila's
build, I'm still getting crashes, but more seems to work.
I've attached the dump from the crash. To reproduce:
1. grab and unpack a JRuby nightly from
2. set MLVM into JAVA_HOME
3. run
Okay, I think I got it... my hg tip for bsd-port was okay:
changeset: 125:428565383a55
tag: tip
parent: 123:75d7dc371aec
parent: 124:5dc862ec024e
user:gle...@misty.eyesbeyond.com
date:Sat Jul 25 20:53:34 2009 -0700
summary: . Merge from main OpenJDK
Attila Szegedi wrote:
Strangely, trying to build using gnumake from davinci/patches/make
will fail; that's why I go back manually to bsd-port. Also, not doing
a ./clean.sh is a bad idea, as it did cause a build to fail in the
past. Anyway, the problem is likely that I failed to update
Ok, fib now runs to completion (see below). I'm uploading a new build;
the URL is
http://files.getdropbox.com/u/362958/mlvm/mlvm-macosx-i586-20090803.tgz
. It will take 1-2 hours as apparently I only have 64KBit/sec uplink
where I am now :-( So, don't start downloading just yet :-)
Attila.
Le 03/08/2009 16:11, Charles Oliver Nutter a écrit :
On Mon, Aug 3, 2009 at 9:15 AM, Rémi Foraxfo...@univ-mlv.fr wrote:
Hi Charles,
I try to compile jruby (1.4.0dev)
and I go an error saying that ivy/build.xml doesn't exists.
So I chnage the line 49 of the build.xml to optionally
to the
Well, I'm out of ideas. All I can say is, it works for me… guess
you'll have to build it yourself.
Attila.
Sent from my ${mobile_handset_device}
On 2009.08.03., at 17:07, Christian Thalinger christian.thalin...@sun.com
wrote:
Charles Oliver Nutter wrote:
For some reason this is still
Ok, finally circled back around to testing things again. With Attila's
build, I'm still getting crashes, but more seems to work.
I've attached the dump from the crash. To reproduce:
1. grab and unpack a JRuby nightly from
2. set MLVM into JAVA_HOME
3. run bin/jruby
I too managed to crash it yesterday, but it turned out I accidentally
emitted invalid bytecode from ASM - I forgot to end the binary name of
a class with semicolon in method signature of an invokedynamic
instruction. Amazingly, neither ASM nor the verifier caught it. The
crash message was
This is another error here.
GuardWithTest adapter try to report a NPE but
fillInStackTrace() crash when walking the stack to gather all frames.
The good question is how GuardWithTest can throw a NPE
knowing that test, target and fallback are null checked before
its creation.
By the way, John :
On Sun, Aug 2, 2009 at 5:21 PM, Rémi Foraxfo...@univ-mlv.fr wrote:
Charles, could you try with -Xint, just to see if the NPE is still thrown or
not ?
With -Xint it works fine, and runs fib(30) for as long as I choose to
let it run.
- Charlie
___
On Sun, Aug 2, 2009 at 3:12 PM, Charles Oliver
Nutterhead...@headius.com wrote:
Ok, finally circled back around to testing things again. With Attila's
build, I'm still getting crashes, but more seems to work.
I've attached the dump from the crash. To reproduce:
1. grab and unpack a JRuby
35 matches
Mail list logo
