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
14 matches
Mail list logo
