Supplanting BCI solutions

[Kasra Faghihi]

Users should have the option to look at and modify the contents of a
suspended call stack at runtime. This includes...

 * local variable tables
 * operand stacks
 * suspension points
 * any signatures / identifiers

The main reason for this is versioning.

For example... imagine that you suspend a fiber and serialize it out to
disk. You then shut down your app, make some code changes, and start it
back up. When you attempt to deserialize and continue that fiber, your
application crashes. The code changes you made shifted around the compiled
bytecode in such a way that the fiber isn't be loadable anymore (e.g. some
LVT slots get removed or shifted around).

When you give users the option of modifying a suspended call stack at
runtime, they can detect if that suspended call stack is for an old version
and apply the necessary changes to get it into a loadable state. You could
make the argument that users shouldn't be exposed to low-level aspects of
the Java like this, but keep in mind that third-party tool writers such as
myself will likely build stuff on top of this feature to abstract much of
the complexity away. I imagine that the API for this, if provided, would be
a niche feature similar to the Java Agent API.

There are a broad range of use-cases for this, but they all pretty much
boil down to one thing: being able to make changes without blowing away
state. I use my own BCI tool's versioning support to prevent blowing away
my actors when I do a rolling software update (actors = fibers for my
case). Game developers could use versioning support to load up game saves
from previous versions of their game (assuming game logic was written using
fibers).

When you have maybe 20 minutes to kill, glance through
https://github.com/offbynull/coroutines#serialization-and-versioning-guide.
It'll give you a feel for how my BCI solution works. There's flexibility
built into it that I don't expect replicated in loom. For example, it
supports bidirectional versioning -- newer versions of your software will
deserialize fibers from older versions, but newer versions can also
serialize in such a way that older versions can deserialize as well.

As long as the underlying pieces are there, users can build the rest
themselves.


Let me know if anything was unclear.

- Kasra




On 22 February 2018 at 07:42, Ron Pressler <ron.pressler at oracle.com> wrote:

> Hi Kasra.
>
> Can you explain what you mean by "user-level manipulation of the lvts and
> operand stacks in a suspended callstack" and why this is important?
>
> Ron
>
>
> On February 20, 2018 at 5:25:32 PM, Kasra Faghihi (offbynull at gmail.com
> (mailto:offbynull at gmail.com)) wrote:
>
> > Hi,
> >
> > I maintain an opensource BCI coroutines/fibers tool for Java:
> > https://github.com/offbynull/coroutines. I know you folks have many
> fancy
> > things planned for this feature, but here's what me (and many of my
> users)
> > would like to see...
> >
> > 1. suspend/resume a callstack
> > 2. user-level manipulation of the lvts and operand stacks in a suspended
> > callstack
> > 3. serialization and versioning support (aka checkpointing) of a
> suspended
> > callstack
> >
> > Item 3 may be a bit of a stretch, but as long as item 2 is available
> users
> > can implement this themselves.
> >
> > Right now, my tool implements all 3 items. The best case scenario for me
> > would be to deprecate the tool entirely in favour of this new feature.
> Let
> > me know if I can help in anyway.
> >
> > - Kasra
>
>

On 22 February 2018 at 07:42, Ron Pressler <ron.pressler at oracle.com> wrote:

> Hi Kasra.
>
> Can you explain what you mean by "user-level manipulation of the lvts and
> operand stacks in a suspended callstack" and why this is important?
>
> Ron
>
>
> On February 20, 2018 at 5:25:32 PM, Kasra Faghihi (offbynull at gmail.com
> (mailto:offbynull at gmail.com)) wrote:
>
> > Hi,
> >
> > I maintain an opensource BCI coroutines/fibers tool for Java:
> > https://github.com/offbynull/coroutines. I know you folks have many
> fancy
> > things planned for this feature, but here's what me (and many of my
> users)
> > would like to see...
> >
> > 1. suspend/resume a callstack
> > 2. user-level manipulation of the lvts and operand stacks in a suspended
> > callstack
> > 3. serialization and versioning support (aka checkpointing) of a
> suspended
> > callstack
> >
> > Item 3 may be a bit of a stretch, but as long as item 2 is available
> users
> > can implement this themselves.
> >
> > Right now, my tool implements all 3 items. The best case scenario for me
> > would be to deprecate the tool entirely in favour of this new feature.
> Let
> > me know if I can help in anyway.
> >
> > - Kasra
>
>