[mwhicks1]

I was just about to point you to this paper (I'm a co-author), but you beat me to it. The JVM has a fix-and-continue updating feature that perhaps replacing method bodies as long as (a) the method is not running, and (b) it has the same type as before. This approach is limiting and also slow, which directed us to use bytecode transformation. The Rubah implementation is pretty robust at this point, at least for research software. Your reference to "trampoline code" should probably clarify: You just need ways to "restart" your threads, as you do in Kitsune. You don't have to insert trampolines for every updated method, as some prior approaches require.

[paulasmuth]

Thanks for the clarification! I understand that you got rid of the "trampoline"/dispatch code for calling methods by rewriting the respective bytecode at runtime. But you still need to register file descriptors and such with some rubah runtime code, and that piece of rubah runtime code doesn't get replaced on process upgrade, right?

I guess this really doesn't matter from the user's point of view, just for the sake of curiosity, want to work out that/if there seems to be a fundamental difference (FWIW) between what rubah is doing which I understand as "hot patch the code within the running process and have some kind of 'trampoline'/dispatch code within that process to switch between new and old version, regardless if it is actual explicit code or just implicit in the rewritten bytecode, but never actually leave that original process" vs. what you'd do in native code on linux which is more like "tell the kernel to start a proper new process and then pass all open fd's and programm state to the new process" (which obviously requires that process to be written in a way that allows it to "continue where it left off") --- and the latter is not possible to do when running on the stock jvm if I understand correctly, because the jvm doesn't allow you to implement the part where you pass the filedescriptors, right?

[mwhicks1]

There's no need to register file descriptors, since these stay open during the upgrade -- the process identity doesn't change.

As far as a fundamental difference with the approach you propose: We actually tried it with an earlier system called Ekiden. We found that updating by migration was slower and more cumbersome than updating in place, but I don't believe there were fundamental issues. If you look at the related work section of the Kitsune paper you'll see a nice comparison with all known approaches, as well as Ekiden.