Live data from Hacker News

Java Virtual Machine in pure Node.js

github.com

121–130 of 143 posts

Re: Java Virtual Machine in pure Node.js

#121
post #41

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…

Looks great. How is the performance, do you expect to be able to produce guis(awt/swing) soon?

Thanks!

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/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.

Re: Java Virtual Machine in pure Node.js

#122

Earlier quoted context omitted.

I'm thinking the next big step is to build ASIC's with hierarchical memory sub-systems that can quickly load and execute either x86 or ARM instructions, kind of like binary run-times implemented in hardware, and then boot operating systems on them so that programs don't have to worry about the physical memory address layout or disk file-systems, and then finally run a compiled version of the JVM that includes hot-spo…

What you're describing sounds like how computers work now. What I see as the logical next step is to design chips that use Javascript as their instruction set, because in the future, every layer underneath Javascript will just be overhead, because everything will be Javascript. We might as well start planning for it now.

What I really want to say is that you can turn my kernel calls into JSON-RPC when you pry my ARM assembler from my cold, dead fingers.

Re: Java Virtual Machine in pure Node.js

#124
post #83

Really cool hack, and yet I can't help but think that the mile-high software stack between the developer and the CPU continues to grow meaning we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. I'm sure I'll see a demo showing off something that barely runs on modern hardware that we were more than capable of running with good performance in 1990. sigh I feel like I'm being suc…

>we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. There are lots of CPU cycles, and plenty of cases where trading a few for increased flexibility makes a ton of sense.

Not to the users who sit around watching swirlies and beachballs. They don't care what rad, flavor of the month framework you used to build your software. Websites and desktop apps were more responsive in 1998 than they are today*

*In general and not supported by facts of any kind other than my own anecdotia.

Re: Java Virtual Machine in pure Node.js

#125
post #83

Really cool hack, and yet I can't help but think that the mile-high software stack between the developer and the CPU continues to grow meaning we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. I'm sure I'll see a demo showing off something that barely runs on modern hardware that we were more than capable of running with good performance in 1990. sigh I feel like I'm being suc…

the differences are in how quickly the software can get written, and where that software can go to be run, and in how many different places. It could be we haven't improved those either, but there's more to life than raw performance you see.

I agree, but then again, I remember the days when any given piece of software was ported to a dozen competing home computing platforms with wildly different architectures and operating systems as a matter of course. These days we basically have 2 architectures and 3 or 4 different OSs and that's about it.

Looking at lots of "web-scale" technologies, I can't help but think that lots of what we're trying to solve with racks of computers could probably be handled with ease by a single modern machine if the software wasn't so inefficient.

Re: Java Virtual Machine in pure Node.js

#126
post #110

Earlier quoted context omitted.

The paradigm is that it's easier (cheaper) to have less performant code that takes less time to build for developers then it is to have maximum performant code... This project at least provides the potential for people like myself who have existing Java projects with longstanding functioning methods that I don't want to rewrite in Node.js... Yes it's another layer, but for some functions that layer can be less compli…

> This project at least provides the potential for people like myself who have existing Java projects with longstanding functioning methods that I don't want to rewrite in Node.js In this case, wouldn't a java-to-js translator be more efficient than rewriting the whole jvm for Node.js?

There's only one way to find out ;)

Re: Java Virtual Machine in pure Node.js

#127
post #43

Now, my question is. WHY!? I might be crazy, but does anyone see a legitimate use for this?

I would argue you haven't really learned how to program until you implement some kind of machine yourself or at least written a compiler. He probably has a very intimate understanding of how all that works now, and I bet he did it for that reason alone.

Yes, yes and you can't DJ without crates of vinyl and 2 turntables. I'll get off your lawn now

Re: Java Virtual Machine in pure Node.js

#128
post #125

Earlier quoted context omitted.

the differences are in how quickly the software can get written, and where that software can go to be run, and in how many different places. It could be we haven't improved those either, but there's more to life than raw performance you see.

I agree, but then again, I remember the days when any given piece of software was ported to a dozen competing home computing platforms with wildly different architectures and operating systems as a matter of course. These days we basically have 2 architectures and 3 or 4 different OSs and that's about it. Looking at lots of "web-scale" technologies, I can't help but think that lots of what we're trying to solve with…

You have a point. But then, what I remember about that software that was ported to all the different architectures was:

1. the software was an order of magnitude or two less complex- in terms of features and platform. That is, there was maybe a dozen different kinds of (highly predictable,testable) home computers instead of a combinatorial infinity of videocards/motherboards/soundcards/operating systems/etc.., plus, the GUI/Evented model is more conceptually difficult for programmers to cope with than straightforward "I own the machine" imperative blocking code. If we want to have guis, we need languages that either abtract away events, or at least provide tools to more easily handle events than C or assembler could provide. Such languages tend to be fairly complex (in implementation)/"inefficient"/garbage collected (since events link to memory/state that must be disposed of eventually,somehow, safely,without segfaulting). Failing that, we need programmers that are smart and capable enough to just plow through the complexity of events in plain C or C++. It's a different caliber of programmer than those who could singlehandedly make simple computer games on an 8-bit home microcomputer.

2. In cases of more complex software, ports were achieved by first designing and implementing a one off virtual machine, then simply porting the virtual machine to the different platforms. See ScummVM, Z-machine, Another World, etc. Surely that threw away some notion of efficiency. You made up for it by implementing the performance sensitive routines inside the VM itself.

3. The inefficiency of software is usually a tradeoff for development speed. To make a virtual platform work consistently across the many different real platforms they must run on, the efficiency of the virtual platform becomes (roughly) a function of ( platform implementors / platform count ) * time. We're only 5 years down the road of this round of serious javascript optimisation. At the end of the day, the curve of that function isn't that different from java, or C or C++ or anything else. those other things just have a huge head start.

Re: Java Virtual Machine in pure Node.js

#129

Earlier quoted context omitted.

What you're describing sounds like how computers work now. What I see as the logical next step is to design chips that use Javascript as their instruction set, because in the future, every layer underneath Javascript will just be overhead, because everything will be Javascript. We might as well start planning for it now.

like a chip that runs asm.js directly as its instruction set, and a js interpreter written in asm.js, with javascript runtime semantics implemented in hardware? kind of like the espruino but even moreso?

I didn't know of asm.js and espruino before you mentioned them, but it looks like the future may be coming sooner than I thought.

Re: Java Virtual Machine in pure Node.js

#130

Earlier quoted context omitted.

>we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. There are lots of CPU cycles, and plenty of cases where trading a few for increased flexibility makes a ton of sense.

Not to the users who sit around watching swirlies and beachballs. They don't care what rad, flavor of the month framework you used to build your software. Websites and desktop apps were more responsive in 1998 than they are today* *In general and not supported by facts of any kind other than my own anecdotia.

beachballs are for IO. You should have an SSD and banish the beachball.
Post reply on HN