Your previous email was sent to me only. I've pasted it below.As you realized, this is not possible:future = makeAsyncCall();while (!future.isFinished()) {makeAnotherStepInTheVM();}...because browser callbacks, such as asynchronous XmlHttpRequests, will not fire until your program stops running and returns to the browser event loop.
@
JavaScriptBody
(args = {"r"},javacall
= true, body = "\n" + " r.@
java.lang.Runnable::run()();\n" + " r.@java.lang.Runnable::run()();\n" + " ") public static native void twoCalls(Runnable r);
Jaroslav's email:Hello John,in addition to previous motivating email, I have to admit I see the problem now:2014-03-22 1:05 GMT+01:00 John Vilk <jv...@cs.umass.edu>:
In Doppio, all JVM method calls are necessarily asynchronous from the JavaScript point of view. We do this because:
- A long running method will freeze the browser, so we need to yield periodically. This is the common case in existing Java code; it's not written in an event-driven style for the web.
- this is not a problem (especially if we add wait4java = false).
- This gives us the freedom to perform a context switch between threads.
- this is not problem either.
- Many of our Java native methods hook up to asynchronous browser functionality (for example, file system operations), which requires JavaScript execution to return to the browser event queue to wait for the callback to fire.
However this one is nasty. One cannot each the browser callback with artificial "while (!isFinished())" loop.
- Classloading in Doppio is asynchronous, as it needs to pull in class information from our file system. If a method called from JS references a class that hasn't been loaded into the classloader yet, Game Over!
This one is not nice either.Unless you change your JVM->JS interoperability story regarding method calls to be asynchronous, this sort of compatibility just fundamentally isn't going to work.The point of JavaScriptBody is to provide 100% interop with GWT. The migration needs to be smooth.We explain why we do this extensively in our paper:That is the same paper as you sent me last time. I have memorized it!In particular, Section 3 explains the strangeness of the browser compared to the native environment, and Section 4 explains the Doppio approach to overcoming it.I have not noticed the problem of a browser callback (bad memory, I guess).Sorry to be the bearer of bad news.That is OK. I was expecting this answer and had the "while (!isFinished())" answer prepared. Too bad it does not work for browser callbacks. But the seek is not over...I'll try to propose something...On Mon, Mar 24, 2014 at 3:21 PM, Jaroslav Tulach <jarosla...@gmail.com> wrote:
Hello John.Here is first part of my email, the optimistic one. Others will follow...
2014-03-22 1:05 GMT+01:00 John Vilk <jv...@cs.umass.edu>:
Hey Jaroslav,Thanks for reaching out again.> Alexey's VM also recognizes @JavaScriptBody annotation as such Bck2Brwsr VM and TeaVM can run the same libraries and applications.Congratulations! I'm happy that you two were able to discuss this and get it working. :)You would not believe how hard it was! Initially Alexey argued that @JavaScriptBody is too general, that it does not fit TeaVM's visiion and that it would be better to use completely different approach (I am sure you can envision the complains). Alexey was of course right - @JavaScriptBody does not optimize for the strongest points of TeaVM. I almost gave up, but then Alexey finished his implemention and I believe he need not be sorry: Now any DukeScript library works well on top of his VM (without even knowing about TeaVM).I am convinced there is a value in having shared "common ground", even if it does not use the best of our VMs.Btw. the @JavaScriptBody does not use the best of Bck2Brwsr VM either. It is a bytecode formalization of GWT's JSNI and its biggest value is that any library written against GWT (and believe me there are some) can be automatically converted to @JavaScriptBody and executed on our VMs.> I would still be interested in Doppio recognizing the annotation as well.
Unfortunately, I don't think this will be feasible. I looked at some sample code for @JavaScriptBody, and it looks like you can call Java methods from the JavaScript. For example, see addColorStopImpl in this following link:In Doppio, all JVM method calls are necessarily asynchronous from the JavaScript point of view.I knew you would have to say this! This is the biggest added value of Doppio compared to Bck2Brwsr VM and TeaVM.I understand the value of asynchronousness and actually the only addition to @JavaScriptBody (in version 0.7.6) was a new attribute "wait4js=false" - which was necessary to make the Android port effective. If you insist, we can certainly let library writers specify "wait4java=false" and be very effective on Doppio.On the other hand, explicit asynchronousness is hard and thinking about it is usually the last thing to do (I tried almost everything to avoid the addition of wait4js). So I am sure library writers will start with synchronous calls - and they need to behave the same on all platforms.That is why Doppio would also have to support synchronous mode. However I know exactly how hard that is:future = makeAsyncCall();while (!future.isFinished()) {makeAnotherStepInTheVM();}While I fully understand the benefits of having Doppio asynchronous mode, I also know that there are no technical reasons to not support synchronous one. Sure, such support may not be nice, in fact it may even be ugly, may go against the beauty of original design, but it would give us ability to run DukeScript and (after conversion) any GWT libraries.We do this because:
- A long running method will freeze the browser, so we need to yield periodically. This is the common case in existing Java code; it's not written in an event-driven style for the web.
A long running method would of course freeze the browser. A pragmatic solution is to write shorter methods, or use wait4java = true.To be continued...-jt
--
You received this message because you are subscribed to the Google Groups "PLASMA at UMass: Google Summer of Code" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plasma-umass-g...@googlegroups.com.
To post to this group, send email to plasma-u...@googlegroups.com.
Visit this group at https://groups.google.com/group/plasma-umass-gsoc.
To view this discussion on the web visit https://groups.google.com/d/msgid/plasma-umass-gsoc/8de3a954-3274-45c0-bf28-b9a12c39f955%40googlegroups.com.
So, from your documentation, if we adopted your name mangling, this bck2browser code:
var r = s.substring__Ljava_lang_String_2II(0, 5);
... would become the following Doppio code:
s.substring__Ljava_lang_String_2II(0, 5, function(r) {
// Rest of function logic
});
This is the price we have to pay for multithreading support and for emulating synchronous Java APIs using asynchronous JavaScript APIs.