7 ms·
Interesting! It looks like you've reimplemented portions of the Java Class Library rather than use e.g the existing class files from OpenJDK. My current resear
by jvilk 13y ago
Interesting! It looks like you've reimplemented portions of the Java Class Library rather than use e.g the existing class files from OpenJDK.
My current research project, Doppio [1], implements the native portions of the OpenJDK Java Class Library so it can use an unmodified copy of the OpenJDK JCL. As a result, it can run a bunch of nontrivial programs (javac/javap/Rhino/Kawa-Scheme).
One issue you will run into is with multithreading. Since JavaScript has no true threading implementation with shared memory, you'll need to be able to suspend and resume virtual JVM threads. For this reason, Doppio maintains an explicit JVM stack representation.
Anyway, feel free to check out our code, reuse portions of it, or contribute if you're interested; it's MIT Licensed and under active development. :)
[1] Demo: http://doppiojvm.org/ http://doppiojvm.org/ Code: https://github.com/int3/doppio https://github.com/int3/doppio
- ajross 13y agoSeems like the "reimplemented" portions are bits that need to interact directly with the script environment -- String is implemented in terms of V8's native strings, etc... That seems like a feature, not a bug -- you wouldn't want the interpreter needlessly doing bytewise diddling of an abstraction that is already very robust in the host environment.
- jvilk 13y agoIn the Java Class Library, any function that needs to interact with the environment outside of the JVM itself (OS/file system/network/threading/etc.) is implemented in C and is marked as 'native'. Those are the functions that we explicitly implement for the JavaScript/browser environment. You are right that we could extract more performance by mapping particular classes directly onto efficient browser functionality -- such as String. In the future, we could implement specific classes such as String directly in JavaScript for a performance boost. :) As a side note, ASM.js itself does not have a String type, which leads me to believe that this particular optimization might not be beneficial if we switch to an efficient JIT strategy.
- gsnedders 13y agoasm.js doesn't because C doesn't, fundamentally. Given both Java and JavaScript strings are immutable, you probably want to for the sake of having non-copying operations for substring and the like.
- drtse4 13y agoNice experiment and a huge undertaking, do you already support the current implementation of java.util.concurrent? (requires atomic CAS through sun.misc.Unsafe and ability to park threads)
- jvilk 13y agoWe have the ability to park threads and atomic CAS implemented, so we should support java.util.concurrent. Granted, it's possible that it invokes a native function somewhere deep inside itself that we don't implement yet, but fixing those are usually very simple.
- jvilk 13y agoNote that the demo is somewhat old; I do not know if it has park implemented. You'll want to build it from GitHub, which we've made relatively straightforward. We are planning to update the demo (and perhaps post on HN) once I fix some IE issues (since we strive to be compatible with IE9).
- arikrak 13y agoIs this used in actual apps?
- jvilk 13y agoRight now, http://codemoo.com/ http://codemoo.com/ by the University of Illinois uses it to teach Java. A few teachers have expressed interest in using it for similar purposes, but we need to make deployment easier. It's too slow at the moment for production use, since it is an interpreter. But if we add JIT compilation support, I believe it will be fast enough for usably running legacy code/libraries in the browser.
- smrtinsert 13y agoLooks great. How is the performance, do you expect to be able to produce guis(awt/swing) soon?
- jvilk 13y agoThanks! We had an excellent Google Summer of Code student work on AWT support for half of the summer. We discovered that the OpenJDK AWT implementation betrays its own internal abstractions, making it impossible to implement a new backend without forking the Java Class Library and making nontrivial changes. You can read more about the problem here: http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-March/000082.html http://mail.openjdk.java.net/pipermail/challenge-discuss/200... Unfortunately, the project described in the above link appears to be defunct and unmaintained. :( We don't have the resources to work further on the problem at the moment. Regarding performance, we are about 20-40X slower than the HotSpot Interpreter in Google Chrome, with similar numbers in other browsers. There is a significant amount of work that we can and plan to do to make that much better, though.