Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java Virtual Machine in pure Node.js

github.com

Post reply on HN
Print view View original

91–100 of 143 posts

Re: Java Virtual Machine in pure Node.js

#91

Post by TheZenPsycho »

bane wrote: 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.

Re: Java Virtual Machine in pure Node.js

#92

Post by jvilk »

drtse4 wrote: post #89
jvilk wrote: 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…

Nice 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)

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

Re: Java Virtual Machine in pure Node.js

#93

Post by TheZenPsycho »

mtdewcmu wrote: post #56
angersock wrote: post #38

Earlier quoted context omitted.

Hey, if you want your precious node back, you can then just run Rhino on the JVM on the node.

Why not just use the javascript x86 emulator that somebody posted to boot an OS? Then you can run the Hotspot JVM, v8, ad infinitum. Piece of cake.

Hotspot runs the program faster than V8? no problem.

Emulate x86 in v8 run hotspot inside emulator.

now you got your performance back.

Re: Java Virtual Machine in pure Node.js

#94

Post by jvilk »

ajross wrote: post #82
jvilk wrote: 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…

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

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

Re: Java Virtual Machine in pure Node.js

#95

Post by jvilk »

drtse4 wrote: post #89
jvilk wrote: 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…

Nice 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)

Note 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).

Re: Java Virtual Machine in pure Node.js

#97

Post by ahoge »

mtdewcmu wrote: post #63
dlsym wrote: post #12

18ms for calculating Fibonacci numbers from 1 to 10. This is definitily bringing JAVA back to the good old days of enterprise execution speeds. :-) Really cool proof of concept! I would really enjoy seeing more projects like this!

Who doesn't wish it was still 1999? Hot stock market, millenium mania, cheap gas, dot-coms. Really slow Java makes it all come rushing back.

> [1999's] slow Java

Java 1.2 (1998) used a JIT and a generational collector. It was probably faster than today's Ruby, Python, or PHP.

What was slow was start up. Applets in particular were really horrible since they completely froze the browser for several seconds.

If I remember correctly, this was finally fixed many years later with some version of Java 6.0.

Re: Java Virtual Machine in pure Node.js

#98

Post by th3byrdm4n »

bane wrote: 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 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 complicated then reimplementation.

Re: Java Virtual Machine in pure Node.js

#99

Post by macspoofing »

bane wrote: 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.

Re: Java Virtual Machine in pure Node.js

#100

Post by arikrak »

jvilk wrote: 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…

Is this used in actual apps?
Post reply on HN