Re:Java Polyfill for the Browser
by javapoly on Sunday May 08, 2016 @04:55PM
(#11655778)
You can use simulated threads with JavaPoly, which allows you to utilize the full Java threading model (including locks). If you enable the native jvm, you get true threads.
The reason you wouldn't want to use WebWorkers as a primitive for building threads is that the javascript memory model doesn't allow for shared memory, so you would take a huge performance hit while crossing the serialization boundary for virtually every memory access. You'd be better off just using the simulated threads at that point.
[ Parent
| on HN ]
Re:Java Polyfill for the Browser
by moron4hire on Sunday May 08, 2016 @05:24PM
(#11655922)
Just a note: shared memory is coming and I think Firefox Nightly has an experimental version that you can enable in about:config.
It's true that SharedArrayBuffer is coming, but there's no way to share objects from what I understand. Since Doppio maps JVM objects to JS objects, it cannot take advantage of shared array buffers to emulate shared memory threads.
Re:Java Polyfill for the Browser
by moron4hire on Sunday May 08, 2016 @09:13PM
(#11656943)
Well, at some point, all objects are just a blob of bytes.
Well, if we represented objects with a blob of bytes, we would have to implement our own garbage collector and manage our own heap, as object references would just be a pointer that points into an array somewhere.
For interop with JavaScript, there's a usability difference between a JavaScript object and a blob of bytes, although that could be overcome with an object "mirror" that proxies operations appropriately.
Our approach was to leverage the existing GC and language features that browsers already have.