[javaflow] byte code instrumentation

[Kohsuke Kawaguchi <kk...@kohsuke.org>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [javaflow] byte code instrumentation

[Torsten Curdt <tc...@apache.org>]

> 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

Re: [javaflow] byte code instrumentation

[Kohsuke Kawaguchi <Ko...@Sun.COM>]

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                   kohsuke.kawaguchi@sun.com

Re: [javaflow] byte code instrumentation

[Torsten Curdt <tc...@apache.org>]

> 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