I've played a little with Juby just to see if the backport is able to
work with JRuby env.
It takes me some times to setup the environment, discovered how ruby
gems works,
use the right version of jruby, etc :)
Ok, the backport works even if I've discovered
that current recompilation thresholds
Jochen Theodorou wrote:
Christian Thalinger schrieb:
Jochen Theodorou wrote:
Christian Thalinger schrieb:
[...]
Currently only 32-bit x86 works, no 64-bit support yet. We decided to
use x86_32 as our main development architecture and port stuff to the
other architectures later, when it's
Jochen Theodorou wrote:
it looks like I am really too stupid for this to build. I manage to
build the openjdk, but the mlvm I spend another full day just on
trying getting this run :(
I try to answer all your questions.
I was too fast the last time, I think I did build the jvm
Christian Thalinger schrieb:
Jochen Theodorou wrote:
it looks like I am really too stupid for this to build. I manage to
build the openjdk, but the mlvm I spend another full day just on
trying getting this run :(
I try to answer all your questions.
thank you very much!
I was too
Christian Thalinger schrieb:
[...]
diff --git a/src/cpu/x86/vm/methodHandles_x86.cpp
b/src/cpu/x86/vm/methodHandles_x86.cpp
--- a/src/cpu/x86/vm/methodHandles_x86.cpp
+++ b/src/cpu/x86/vm/methodHandles_x86.cpp
@@ -273,7 +273,7 @@ void trace_method_handle_stub(const char
Christian Thalinger schrieb:
[...]
Currently only 32-bit x86 works, no 64-bit support yet. We decided to
use x86_32 as our main development architecture and port stuff to the
other architectures later, when it's proven to work.
looks like I am supposed to run that VM with 32bit libs too...
Jochen Theodorou wrote:
Christian Thalinger schrieb:
[...]
Currently only 32-bit x86 works, no 64-bit support yet. We decided to
use x86_32 as our main development architecture and port stuff to the
other architectures later, when it's proven to work.
I think that should be mentioned
Hi John,
Thank you for this info!
Yes, I have just built the mlvm yesterday before your mail to Christian.
Chanwit
On Tue, Jun 23, 2009 at 3:42 AM, John Rosejohn.r...@sun.com wrote:
That reminds me of a bug we fixed in the mlvm patches during JavaOne;
it was a heap stomping problem. I don't
If you pull and build again, you can stop using -Xint. (I hope. :-)
-- John
On Jun 23, 2009, at 2:49 AM, Chanwit Kaewkasi wrote:
Thank you for this info!
Yes, I have just built the mlvm yesterday before your mail to
Christian.
___
mlvm-dev
Hi,
Some update after rebuilding the mlvm.
Without -Xint, I got unexpected opcode: 186
With -Xint, the program ran fine.
Then I tried -server, I felt like JIT kicked it? The program ran and
finally JVM crashed.
Here's log:
http://gist.github.com/134500
I see something like C2 compiler was
Hi Jochen,
I used Fedora 8, and I needs some patches (see attachment) from the last pull.
Both are to apply to the jdk subproject with -p 1.
HTH,
Chanwit
On Tue, Jun 23, 2009 at 1:19 PM, Jochen Theodoroublackd...@gmx.org wrote:
John Rose schrieb:
If you pull and build again, you can stop
Rémi Forax schrieb:
Jochen Theodorou a écrit :
John Rose schrieb:
If you pull and build again, you can stop using -Xint. (I hope. :-)
John,would it be a problem to make a page on the mlvm project page
explaining exactly how to build mlvm and in what environments it maybe
won't
Chanwit Kaewkasi a écrit :
Hi,
Following Juby, my language G7 is a Groovy-like language that also
compiles to invokedynamic ;-)
I use Groovy parser, remove its MOP layer and rewrite the code
generation class. The idea of wiring up invokedynamic is taken from
Juby implementation.
It runs
A quick update. It seems to be the out-of-memory crash.
I re-ran with:
$ java -Xms512M -Xmx512M -cp .;./target/classes -Xint
-XX:+EnableInvokeDynamic g7.tests.classgen.Fib
5
55
610
6765
75025
832040
9227465
And thing works fine.
Chanwit
On Mon, Jun 22, 2009 at 2:28 PM, Chanwit
It's more a GC crash, with more memory you don't trigger the GC, that
why it's working fine.
In the dump of your previous email:
VM_Operation (0x0090f7b8): GenCollectForAllocation, mode: safepoint,
requested by thread 0x003e7000
Rémi
Chanwit Kaewkasi a écrit :
A quick update. It seems to be
I thought I'd try building a simple Ruby-like dynamic language that uses
all Java types and invokedynamic. Turns out it's only a couple hour job.
http://gist.github.com/129973
This is Juby, a language that simply compiles Ruby's syntax to Java's
type system. All calls are made using
16 matches
Mail list logo
