[javaflow] byte code instrumentation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[javaflow] byte code instrumentation

Kohsuke Kawaguchi

I've been looking at the disassembled byte code casually.

One thing I noticed is that we are adding two variables to every method;
one is Continuation and the other is Stack.

I wonder if we can reduce this to just one, namely to Stack. Instead of
remembering Thread->Continuation association, we can remember
Thread->Stack association. We then replace
Continuation.currentContinuation() with Stack.currentStack(), and we can
also move relevant flags (like restoring/capturing) to a Stack object.

This also has a nice side-effect of moving methods like
isCapturing/isRestoring to a non-API package. Today, those methods are
defined as public methods of Continuation, as a part of the API class,
even though they aren't supposed to be called by applications.

In this way, we can also make the Continuation truly immutable.

Does this sound reasonable?
--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] byte code instrumentation

Torsten Curdt
> I wonder if we can reduce this to just one, namely to Stack.  
> Instead of remembering Thread->Continuation association, we can  
> remember Thread->Stack association. We then replace  
> Continuation.currentContinuation() with Stack.currentStack(), and  
> we can also move relevant flags (like restoring/capturing) to a  
> Stack object.
>
> This also has a nice side-effect of moving methods like isCapturing/
> isRestoring to a non-API package.

> Today, those methods are defined as public methods of Continuation,  
> as a part of the API class, even though they aren't supposed to be  
> called by applications.
>
> In this way, we can also make the Continuation truly immutable.
>
> Does this sound reasonable?

Well ...it does sound reasonable - except that
isRestoring/isCapturing feels also a bit awkward
inside the Stack class.
Would have been nice to keep that one clean :-/

But on the other hand a clean Continuation interface
and saving some instructions on the bytecode level
does sound very tempting.

...we could also have a specialized Stack with
those flags extending the basic Stack implementation.

WDYT?

cheers
--
Torsten

PGP.sig (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] byte code instrumentation

Kohsuke Kawaguchi-2
Torsten Curdt wrote:

> Well ...it does sound reasonable - except that
> isRestoring/isCapturing feels also a bit awkward
> inside the Stack class.
> Would have been nice to keep that one clean :-/
>
> But on the other hand a clean Continuation interface
> and saving some instructions on the bytecode level
> does sound very tempting.
>
> ..we could also have a specialized Stack with
> those flags extending the basic Stack implementation.
>
> WDYT?
OK. we'll keep the current Stack class intact and extend it.
We won't be using the basic Stack implementation by itself, but rather
we'll be always using the extended Stack class. So the distinction seems
bit odd, but I see why you'd want to do it.

It's also very easy to merge those two classes into one later if we want
to do so.


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] byte code instrumentation

Torsten Curdt
> OK. we'll keep the current Stack class intact and extend it.
> We won't be using the basic Stack implementation by itself, but  
> rather we'll be always using the extended Stack class. So the  
> distinction seems bit odd, but I see why you'd want to do it.
>
> It's also very easy to merge those two classes into one later if we  
> want to do so.

Sure ...cool bananas

cheers
--
Torsten


PGP.sig (193 bytes) Download Attachment