|
|
|
|
|
by pron
989 days ago
|
|
Also, imagine a thread does the following: var result = stmt.executeQuery("select from ...");
When the thread blocks on the DB, rather than bring data from a remote machine, the runtime could serialize the thread, send its state over the wire, and unblock it on the machine containing the data. |
|
Is this something you know someone is working on? Maybe at Oracle? Or just a general thought? I follow the loom-dev mailing-list and haven't seen this topic come up.
SSD manufacturers have controllers that checksum the data and manage the blocks. One could even imagine going one step further by having the continuation being sent to the controller and filters and projections being done right there; saving also the SATA bandwidth. Some manufacturers are starting to get there [1]
What about GC in this context, though? Getting over the wire means execution is not guaranteed, the DB server can crash. Continuations stacks' content is scanned for references. Does that mean that the old copy of the continuation is kept there for the GC? And there's a timeout to collect the continuation if it goes silent? What if the remote continuation want to access something in the previous JVM? Should the continuation be scanned before being sent? Can that be a compile-time guarantee? What about exceptions and stacktraces?
[1] https://www.arm.com/blogs/blueprint/computational-storage