I managed to build a MLVM binary today for Mac OS X 10.5 with Intel
CPUs. As I'm not a Sun employee, I can redistribute it under GPL, so
here it is for your own experimentation:
<http://dl.getdropbox.com/u/362958/mlvm/mlvm-macosx-i586-20090419.tgz>
Use at your own risk, and if it doesn't work, well, build a better one
yourself :-)
Seriously, it'd be hard to determine for most defects if they're a bug
in the OpenJDK source code, in a MLVM patch, or in my build process.
Therefore, if you run into a defect, the best way to proceed is to
build it yourself from source code. Of course, if building it yourself
fixed your issue, then I'd love to hear back about what did I do wrong.
Attila.
--
twitter: http://twitter.com/szegedi
-Frank
Every morning right between putting on the coffee and waking up the
kids for school ;-)
Attila.
Attila.
> Hi Ben,
>
> I get exactly the same result with your build:
It's a pain when the tools won't listen to your intended configuration.
One way to investigate (that sometimes helps me) is to look underneath
the tools to see what pathnames they are accessing. On Solaris it is
"truss", on older Macs it is "ktrace", and on Leopard it is "dtrace".
It requires a very modest "sudo" setup. Here's an article on dtrace:
http://www.macosxhints.com/article.php?story=20071031121823710
I have no idea why this should be necessary, but you could try to
force your explicit rt.jar earlier into javac's search order:
javac -Xbootclasspath/p:$myjrelib/rt.jar ...
-- John
> Can you guys run this code, if so, what are your command line options?
I'm in the middle of a different micro-version of the system, so I
don't get the ICCE. (I get something else, which I'm fixing.)
The ICCE is the generic error for a bytecode-level configuration
problem. Are you running a 64-bit JVM? There is no 64-bit support
yet (help?!) and you'll get an ICCE like the one you report.
I need to update the mlvm repo with (a) the results of the push that
just went into the JVM and (b) my latest hackings on the java.dyn and
sun.dyn classes. Please stay tuned.
This pain you feel is reserved for the prestigious group called the
Early Adopters!
-- John
sudo fs_usage | grep javac
(fs_usage must be run as a superuser)
Attila.
MacBook-Pro-Ati:bin aszegedi$ lipo -info java
Non-fat file: java is architecture: i386
"i386" means 32 bit. In contrast, running lipo -info on the Apple-
shipped 1.6.0 java (which is 64-bit) gives "x86_64":
MacBook-Pro-Ati:bin aszegedi$ lipo -info /System/Library/Frameworks/
JavaVM.framework/Versions/1.6.0/Commands/java
Non-fat file: /System/Library/Frameworks/JavaVM.framework/Versions/
1.6.0/Commands/java is architecture: x86_64
So, that MLVM build is definitely 32-bit.
Attila.
MacBook-Pro-Ati:j2sdk-image aszegedi$ bin/javac -Xbootclasspath/p:jre/
lib/rt.jar -source 1.7 Hello.java
MacBook-Pro-Ati:j2sdk-image aszegedi$ bin/java -Xbootclasspath/p:jre/
lib/rt.jar Hello
MacBook-Pro-Ati:j2sdk-image aszegedi$ bin/java -Xbootclasspath/p:jre/
lib/rt.jar -XX:+EnableMethodHandles Hello
Hello, world (from a statically linked call site)
Hello, world
Exception in thread "main" java.lang.IncompatibleClassChangeError
at Hello.main(Hello.java:11)
Attila.
Impressive !
the bootstrap method now returns a call site.
we just agree about that 2 days ago !
And combinators work...
It's a huge leap forward, Champagne !
Rémi
> It's a huge leap forward, Champagne !
Cheers! <sip/> -- John