Regarding multithreading

[TudbuT]

I've recently forked graaljs and forcefully enabled multithreading by removing the throw statement (a very dirty way to do it, i know. i just wanted to test if multithreading works in practice), and the results were surprisingly very good. Compared to other slight interop issues, this one was quite unnoticable. In fact, during multiple benchmarks, i only got minor inconsistencies that can be avoided by not benchmarking and instead using it normally, or writing your code in such a way that two threads don't try to use the same JS variables too much. During normal use, i've had zero issues with 4 threads accessing the context at once.

This is NOT an actual bug report. I just want to make the suggestion to add an option, for example 'js.EnableMultithreading', and making it experimental. There are multiple other issues with interop that don't matter in practice so i think we shouldn't be denied mutithreading completely. I might later start a pull request to add an option (if i manage to add an option that is :/ ).

[wirthi]

Hi @TudbuT ,

There are sane ways to use JavaScript multi-threaded on GraalVM. We have listed them in https://github.com/oracle/graaljs/blob/master/docs/user/Multithreading.md

I don't think we will be easily convinced to adopt and support your suggestion, even in an "experimental" fashion. JavaScript, by the design of the language (ECMAScript), is single-threaded and takes little to no precaution to ensure that sane semantics apply when you execute it in multi-threaded fashion. Problems we have seen (that were e.g. exploitable in Nashorn) were around the object model, where severe data corruption occurs when two threads update the same hidden class (object with identical structure).

Maybe @eleinadani can help you achieve a reasonable solution for your problem without enabling full multi-threading.

[TudbuT]

What kind of data corruption? Maybe i can fix that in my fork.

Do you mean [Class].prototype ? If so, it would be possible to block only that from multithreading.

[eleinadani]

What kind of data corruption? Maybe i can fix that in my fork.

@TudbuT certain (internal) Graal.js components are not thread-safe. One example mentioned above by @wirthi is the internal "object model", which handles object shapes (a.k.a. "hidden classes") and object-related metadata. In that case, multiple threads updating the same internal metadata could lead to data corruption (e.g., wrong values stored in any object, not just the prototype). While solutions exist to mitigate/solve this kind of internal issues, we do not provide thread-safety guarantees at the moment, because concurrent access to JS objects is not specified in the ECMAScript standard. This might change in the future, but providing strong thread-safety guarantees (within a single Context) requires major engine changes.

[TudbuT]

That sounds quite hard to implement... I'm sorry if i was wasting your time, and for now, i will probably just stick to my fork.

To explain why im so obsessed about multithreading: I'm using GraalVM to add plugins to a game, and have previously used Nashorn for it, so i used multithreading quite a lot as Nashorn allowed it.

Thanks for your help and information.

[TudbuT]

I'll leave this open for now, maybe i find some kind of solution. I'll experiment further.

[no0ker]

is there any news about multithreading?

[TudbuT]

I've privately tried making this work, and it seems to just require a few synchronized {} blocks to make all problems i had encountered before disappear, however i won't publish this work as it is very clunky and i have left out a bunch of places because I am unfamiliar with the codebase.

[no0ker]

@eleinadani, maybe, is there any way to execute javascript code on graaljs like on nashorn - multithreading and concurrently (with potentially race conditions)?

[eleinadani]

@no0ker no, Nashorn-like concurrency with potential race conditions is not supported. Our doc contains an overview of the supported models of concurrency

[no0ker]

@eleinadani for example, my application processes 300 rps (it is not highload). every request processed about 3 seconds.. and have i create and hold in memory about 1_000 instances of graaljs? 1_000 instances of graaljs are so expensive for memory... one instance of nashorn is better than 1_000 instances of graaljs, isn't it? =((

[eleinadani]

@no0ker using a single engine to serve multiple (concurrent) requests is potentially unsafe, and is not supported in Graal.js for JavaScript code. All the supported models of concurrent execution are in the doc I've linked to above. To reduce memory consumption, you can share a single Engine across multiple independent Context instances. One example can be found in our documentation here.