4 ms·

I see what it is and I think I understand what it does, at least as far as the high level description goes. I am re-working some C++ code to work when built wit

by sqeaky 10y ago

I see what it is and I think I understand what it does, at least as far as the high level description goes. I am re-working some C++ code to work when built with emscripten as asm.js and I have a passing familiarity with web assembly. But why does this webassembly to JVM bytecode converter exist? Is this some kind of research project? If so, great no more explanation someone wanted to see their limits and learn in the process, great. Is this for some professional purpose? If so then I am much more curious. Who has a need to convert stuff in the browser to JVM code, and what benefit do they gain?

kodablah 10y ago
I touched on it in the README FAQ under "Why?". Basically I am just doing it for fun and becoming more familiar w/ the technologies involved. Also, it's not "convert stuff in the browser", WebAssembly has non-web goals [0]. There can be benefit in libraries sharing a common bytecode. 0 - http://webassembly.org/docs/non-web/ http://webassembly.org/docs/non-web/
- sqeaky 10y ago
  "Just for fun" is a great reason. I was unaware of the non-web goals of WebAssembly, Thank you.
spullara 10y ago
It is theoretically possible though not likely that you could get better performance on the JVM than a static compiler due to runtime optimizations on hot code paths.
wrmsr 10y ago
It's not about converting stuff in the browser to the jvm, it's about converting existing c and c++ (and others) to the jvm via an intermediate format primarily (but not exclusively) designed for the browser. There are real reasons to 'rewrite-it-in-java' beyond just NIH, to the degree that even without this automatic transpiling it's frequently done (grpc-c vs grpc-java, all jdbc drivers, etc): - Native transitions are expensive - not just through register saving and gc machinery but also because native code is opaque to the optimizer. Runtime virtual inlining is probably the single most important optimization hotspot does and the more frequently code it can't work with is called the worse everything gets. While it's almost certainly nothing to worry about with coarse-grained syscalls, and probably not too much to worry about with things like opengl calls, I'd be very skeptical of using, say, a native database driver involving native transitions to retrieve every field of every row of every query in a db-heavy app. This is much the same way pypy is usually much happier with pure-python code than with native code - the more your vm does for you the less happy it is when it can't do it. Furthermore, as these binaries are the compiled results of clang and llvm (just with a different backend) the normal static analysis and optimization passes are run on the c source and ir, it just gets compiled down to a simpler instruction set than most modern physical machines. - Native deps are anathema to most clean java projects. Our de-facto dep system, maven (and compatibles), is entirely jar-centric. The 'accepted' solution for distributing something like sqlite is some poor person having compiled the native libraries on (win|lin|osx)(32|64), zipped them all up into a big ol jar, and put that single blob on maven. On boot it sees what platform its on, extracts the lib to a temp dir, loads it, then imports a jni binding for it. Inelegant to say the least, especially when java people tend to be spoiled by the notion of there being no difference between an osx or linux build or binary. - Debugging is worlds nicer when everything's in the jvm, even before stackmaps. You only need one debugger, it's nice and graphical, you can run it remotely with no such thing as a 'debug build', it basically never segfaults, et cetera.

by sqeaky 10y ago

kodablah 10y ago

I touched on it in the README FAQ under "Why?". Basically I am just doing it for fun and becoming more familiar w/ the technologies involved. Also, it's not "convert stuff in the browser", WebAssembly has non-web goals [0]. There can be benefit in libraries sharing a common bytecode. 0 - http://webassembly.org/docs/non-web/ http://webassembly.org/docs/non-web/

sqeaky 10y ago
"Just for fun" is a great reason. I was unaware of the non-web goals of WebAssembly, Thank you.

spullara 10y ago

It is theoretically possible though not likely that you could get better performance on the JVM than a static compiler due to runtime optimizations on hot code paths.

wrmsr 10y ago

It's not about converting stuff in the browser to the jvm, it's about converting existing c and c++ (and others) to the jvm via an intermediate format primarily (but not exclusively) designed for the browser. There are real reasons to 'rewrite-it-in-java' beyond just NIH, to the degree that even without this automatic transpiling it's frequently done (grpc-c vs grpc-java, all jdbc drivers, etc): - Native transitions are expensive - not just through register saving and gc machinery but also because native code is opaque to the optimizer. Runtime virtual inlining is probably the single most important optimization hotspot does and the more frequently code it can't work with is called the worse everything gets. While it's almost certainly nothing to worry about with coarse-grained syscalls, and probably not too much to worry about with things like opengl calls, I'd be very skeptical of using, say, a native database driver involving native transitions to retrieve every field of every row of every query in a db-heavy app. This is much the same way pypy is usually much happier with pure-python code than with native code - the more your vm does for you the less happy it is when it can't do it. Furthermore, as these binaries are the compiled results of clang and llvm (just with a different backend) the normal static analysis and optimization passes are run on the c source and ir, it just gets compiled down to a simpler instruction set than most modern physical machines. - Native deps are anathema to most clean java projects. Our de-facto dep system, maven (and compatibles), is entirely jar-centric. The 'accepted' solution for distributing something like sqlite is some poor person having compiled the native libraries on (win|lin|osx)(32|64), zipped them all up into a big ol jar, and put that single blob on maven. On boot it sees what platform its on, extracts the lib to a temp dir, loads it, then imports a jni binding for it. Inelegant to say the least, especially when java people tend to be spoiled by the notion of there being no difference between an osx or linux build or binary. - Debugging is worlds nicer when everything's in the jvm, even before stackmaps. You only need one debugger, it's nice and graphical, you can run it remotely with no such thing as a 'debug build', it basically never segfaults, et cetera.