After seeing this I wanted to know:
- how many opcodes exist in the JVM
- how easy would it be to create another language that compiles to the JVM.
- how does the JVM represent basic data types
The list goes on. All because someone built a JVM in JS.
What happened to the hacker mentality of HN? Where's the curiosity gone?
Most platforms in use today are so complex. Take a look at x86, or one of the latest ECMAScript specifications. Even LLVM bitcode is a bit complicated compared to the JVM bytecode.
I think in programming language research, going forward, we need some research into "high-level bytecodes". I.e. bytecodes that capture high-level concepts in a clear and simple way.
JVM: dadd, fadd, iadd, ladd. Addition for double, float, int, and long data, respectively.
CIL: add, add.ovf, add.ovf.un. Addition, signed addition with overflow check, and unsigned addition with overflow check.
You can see this design choice even today in how the JVM and CLR work. The JVM starts execution in an interpreter mode, then gradually compiles pieces of code as it detects bottlenecks. So the compilation that happens at runtime is very gradual and based on runtime measurements.
The CLR on the other hand has done JIT compilation, with the ability to cache the compiled code for faster startup (e.g. Ngen). So it has been oriented towards ahead of time compilation.
JVM - Bytecodes only for Java
CIL - Bytecodes for VB.NET, C#, Managed C++ and the 1.0 SDK contained examples for Lisp, Pascal, Eiffel, Ada, ....
Of course, history then took another path for the JVM.
EDIT: Forgot that C++/CLI replaced Managed C++, which was the C++ variant on 1.0.
Although it should be mentioned that java language semantics are largely (depending on how you measure them :-) absent from the jvm. (Default methods were a very unusual change in that respect)
And, as you say, subsequent history has weirdly inverted the JVM and CIL. The former is a lot less 'J' and the latter is a lot less 'C' ;-)
(I was really referring to the healthy non-java jvm language community. JRuby, Scala, and Clojure have lively communities and commercial backing)
IMHO WebAssembly solves that better but I also need to admit that they could already learn from Java.
While that may be true of the language Java, WebAssembly's jump instructions are not without their annoyances too. For example, the JVM bytecode requires your stack to be precise when jumping, WebAssembly just cares about the most recent piece. If you expect your jump targets to have the same stack layout, WebAssembly makes the impl handle it. I had to account for this and other differences in my compiler .
0 - https://github.com/cretz/asmble#control-flow-operations
The specification is dense but still readable. I'd start reading in order, up through the third chapter which explains how to compile various Java snippets to bytecode. Perhaps start there and go back to the second chapter when you need more context.
I've also found this old but still relevant book to be a good guide: http://www.artima.com/insidejvm/ed2/
Byte Code is simple:
(I can't speak to the quality of either of these tests, but the results seem decisive)
One reason Nashorn isn't used that much is that it doesn't expose a node.js compatible API. JS people often want Node specifically, not just the ability to run JS. It has some cool features though. The shell mode is neat.
I imagine that once they update it to Java 9 with the modular JDK (and resultant splitting of rt.jar) this reduction will largely happen automatically with it lazily downloading the parts that it needs.
It was targeted toward running J2ME apps on FirefoxOS phones. With that project dead it's no longer under active development.
0 - https://github.com/zxh0/jvm.go
1 - https://github.com/cretz/goahead
that makes it possible to run unaltered applications written in generalpurpose
languages directly inside the browser.
Someone should really have told them about webassembly...
One year before asm.js appeared, in Mar 2013
Three years before WebAssembly appeared, in June 2015
Five years later, In 2017, WebAssembly still doesn't have a GC and cannot run the Java/Scala/Groovy programs that Doppio was able to run in 2012
Doppio proper (the repository you refer to) started during the spring meeting of 691. Those guys went above and beyond the minimal spec we implemented, and they tackled a lot of stuff that we thought was impossible. Thus the research paper.
IIRC, we also had to write a decentralized chat program in JS that semester. That was also "fun".
Yes, I created a HN account just to post this.
Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR?
A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions we intend to introduce garbage collection and structured data based on the ES6 structured binary data API, which will make asm.js an even better target for managed languages.
I admire the effort, but: doesn't "academic" mean "scientific"? Can there possibly be any "science" in having a well-known VM reimplemented in a well-known programming language?
You may not think this is an important question to answer--and that is your prerogative--but you can't argue that it isn't scientific. One of those other scientific questions is about threading (again, see page 1). BTW, did you know that System.out.println relies on synchronization primitives? You literally cannot write helloworld in Java without invoking a lot of machinery.
No, it doesn't. Or did you forget about music, literature, engineering, business, finance, history, philosophy, dance, art, architecture, nursing, etc.?
It appears as though this was a university project, the kind of project one completes for their masters even. Academic seems to be precisely the right term.
Error extracting doppio_home.zip: Error: ENOENT: No such file or directory., '/persist/vendor/java_home/lib/images/cursors/cursors.properties'
This is an example of research as illustrated by Figure 5 in that paper (known functionality, novel techniques)