-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run the JVM in a WebWorker #127
Comments
currently doesn't work, due to scope issues (browser/node assumes the existence of 'window') also only supports dev mode, for the moment
Current roadblock: The worker lives in its own scope, separate from anything included in More importantly, we can't import the |
I was hoping that WebWorkers would have a way of polling for new messages, but a quick Google didn't find anything. Hmm. As for the For the file system, the easy way out is to completely replace the synchronous API with an asynchronous API that abuses The These changes should preserve compatibility with Node and IE. |
I disabled the Known issues:
Being able to scroll the page while Doppio runs is super fun. ♨️ |
Or, in the case of Firefox, being able to use the web browser while Doppio runs. |
I've been working on this for ( sigh ) a few days now. CJ's initial effort worked, but had one critical issue: The filesystem lived in the JVM. This meant that it could not use If we kept the filesystem in the frontend, we would have to switch over to asynchronous file operations in the JVM. If we put the filesystem in the JVM, we would have to switch over to asynchronous file operations in the frontend and in the JVM, since the JVM would need to use messages to get at Naturally, we decided to keep the filesystem in the frontend. For now, frontend will still use the synchronous file API, since our virtual filesystem is still blocking. At some point, we'll rewrite/refactor it to be asynchronous, which should hopefully make it more amenable to eventual Dropbox/GDrive/etc. integration. :) I'll create an issue for that. There are two daunting subtasks on the road to WebWorker-ization that can be done in master before we hook up magical message passing. I will create an issue for each of these.
Once those are done, my local WebWorker changes (which I dare not commit to the WebWorker branch yet, as the JVM is totally borked) should be able to integrate with master nicely. |
…ion are now asynchronous. As a result, many core JVM operations that previously relied upon having a 'Type' object could no longer be used synchronously because they invoked class lookup functions. In addition, using 'Type' objects for class lookups is ambiguous; classes are defined by their name AND the class loader that loaded them. To fix this, I changed most of these core methods to take ClassFile objects, which is currently the definitive object for reference types. We are moving toward #116; we will soon move away from passing around Type objects and toward passing around ClassFile objects, which has become the standard representation of Java classes. Once we start stashing ClassFile objects in StackFrames for easy access from opcodes and such, we can stop using types in a large number of places. In a move to fix #124, I have changed the function signature for class_lookup / load_class / define_class / jclass_obj to include the class that triggered the lookup / load / etc. This is used to determine the correct ClassLoader to invoke class loading. This is *not* hooked up at the call sites yet since we do not have ClassFiles there to pass in, but we eventually *will* hook those up, which should fix this issue. For #127, as mentioned all class loading is performed in an asynchronous manner. I believe this is the last difficult internal JVM matter that we needed to convert for WebWorker support. I'll be able to port over my frontend changes once the internal details stabilize. I believe #138 is fixed? I need to grep through the code to ensure we no longer use any synchronous node API calls, except for those that work on file descriptors (since those do not invoke file loading/closing). There are a number of new "hacks" denoted with "XXX". Many of these have to do with ClassLoading, which will be fixed once we move toward actually having ClassLoader objects that handle that abstraction. I'll open an issue for that. A few native methods have become a little crufty, especially those related to reflection. Some have to manipulate the stack while in an async_op, and I had to carefully orchestrate their stack changes such that they do not interfere with what async_op does. I may want to consider making a better helper function for these complex tasks, but I suppose that should wait until we have proper Thread objects that have a nice API for manipulating the stack. Other than that, things are looking positive. We should move toward eliminating Type objects and cleaning up the code.
Now that we're using BFS, the synchronicity issues we were having before should be no problem. This issue will probably need to wait until we're done with the Typescript conversion, though, for our sanity's sake. |
Totally agree. Note that this will also complicate any Swing work, but we can deal with that later. EDIT: Note that we will need to add a WebWorker proxy interface to BFS for this. |
The doppio library is separate from the frontend now, so we could potentially do this now. Here's what would be required:
|
What is the status of "in web worker" runtime? can we now run doppio solely from a web worker? We do not need the front end part. Probably a separate question but, is it possible to preload java.lang, java.util, and java.io packages? |
I'm not sure right now, but I'll be looking at this in the next few weeks |
I have no reason to believe that this would not work. This issue refers to exposing a concise API for invoking DoppioJVM in a WebWorker (e.g. |
I think there is no need for an extra API. Just a simple postMessage/onmessage communication protocol would be enough to invoke DoppioVM. A front end API should not be a focal point of DoppioVM. Let the developers find their own way on that front. |
DoppioJVM works just fine in a webworker; I didn't even need to change anything. I just made a commit that switched to using WWs for testing, so I'm closing this out. The only issue currently is a (throughput-based) performance regression in a WebWorker compared with the main thread, which I'm actively investigating. |
We can run DoppioVM only in a web worker because the main thread is already busy with tons of other stuff. Could you open another issue for the performance regression so that we can follow the imrpovements on that? just a thought :). |
Sure, I'll do that. I'd also appreciate stars on this Chrome issue, which seems to be the culprit in Chrome: I haven't checked to see if performance differs in other browsers yet. |
Doppio currently runs in the main JavaScript thread, which causes the browser to be less responsive than desired. While we could "fix" this by yielding the thread more often, this comes with a speed penalty.
For browsers that support it, we should run the JVM in a WebWorker. Note that we are not mapping threads to WebWorkers -- simulating shared memory would be too slow / cumbersome / difficult -- we are mapping JVM instantiations to WebWorkers.
The main JavaScript thread would be responsible for checking for and handling messages sent from the WebWorker for various events, such as:
localStorage
.localStorage
.For browsers that do not support WebWorkers (e.g. IE before 10), we can just simulate WebWorkers in the main JavaScript thread. To improve those web browsers' responsiveness, we could just yield the JavaScript thread after a certain duration of time (easy enough to do in the interpreter).
This should not impact the Node JS frontend. It will just impact how the browser frontend runs the JVM, how the node emulation requests
localStorage
files, how printing to/receiving input from the console works, and any other browser-specific features that we add to Doppio in the future.The text was updated successfully, but these errors were encountered: