bytecode interceptors

[James Strachan <ja...@yahoo.co.uk>]

Saw this in the blogosphere today...

http://kasparov.skife.org/blog/2003/12/01#thank-you-chris

thought it looked interesting.  I wonder if we could look at 
integrating this kind of feature ('baking' an interceptor stack into 
bytecode)

James
-------
http://radio.weblogs.com/0112098/

Re: bytecode interceptors

[Brian McCallister <mc...@forthillcompany.com>]

Chris just pointed me at this discussion -- if we can make the 
intercept library useful for ya'll, let me know. I am putting together 
some benchmarks on various oddities now.

-Brian

On Dec 2, 2003, at 2:29 PM, Chris Nokleberg wrote:

> James Strachan wrote:
>> Saw this in the blogosphere today...
>>
>> http://kasparov.skife.org/blog/2003/12/01#thank-you-chris
>>
>> thought it looked interesting.  I wonder if we could look at 
>> integrating
>> this kind of feature ('baking' an interceptor stack into bytecode)
>
> The implementation isn't going quite that far. It's probably similar 
> to what
> you currently do. A proxy is created that stubs out to a list of
> interceptors. The baking process is probably just freezing that list 
> (maybe
> into an array or something).
>
> What you propose is possible, of course. The savings would be from:
>  - elimination of need for invocation object
>  - no need for invokevirtual method to start invocation process
>  - replacement of invokeinterface calls to actual interceptors with
>    hard-coded invokevirtual calls
>  - removal of synchronization (don't have to prevent chains from being
>    modified during invocation)
>
> Not sure how much of this applies to Geronimo. It's not terribly hard 
> to do,
> but to add something like this to CGLIB I'd obviously want to find a 
> way
> not to have to tie it to Geronimo's interceptor classes. Let me know...
>
> If you have complete control over the container startup and 
> classloading (as
> you probably do) then AOP is a viable solution too, but in general 
> run-time
> code generation is much more portable. FYI CGLIB2 can also use the
> Aspectwerkz "online mode" architecture to hook into the ClassLoaders 
> of the
> various JVMs, but for this use-case it is unnecessary.
>
> Chris
>
>
>

Re: bytecode interceptors

[Chris Nokleberg <ch...@sixlegs.com>]

James Strachan wrote:
> Saw this in the blogosphere today...
> 
> http://kasparov.skife.org/blog/2003/12/01#thank-you-chris
> 
> thought it looked interesting.  I wonder if we could look at integrating
> this kind of feature ('baking' an interceptor stack into bytecode)

The implementation isn't going quite that far. It's probably similar to what
you currently do. A proxy is created that stubs out to a list of
interceptors. The baking process is probably just freezing that list (maybe
into an array or something).

What you propose is possible, of course. The savings would be from:
 - elimination of need for invocation object
 - no need for invokevirtual method to start invocation process
 - replacement of invokeinterface calls to actual interceptors with
   hard-coded invokevirtual calls
 - removal of synchronization (don't have to prevent chains from being   
   modified during invocation)

Not sure how much of this applies to Geronimo. It's not terribly hard to do,
but to add something like this to CGLIB I'd obviously want to find a way
not to have to tie it to Geronimo's interceptor classes. Let me know...

If you have complete control over the container startup and classloading (as
you probably do) then AOP is a viable solution too, but in general run-time
code generation is much more portable. FYI CGLIB2 can also use the
Aspectwerkz "online mode" architecture to hook into the ClassLoaders of the
various JVMs, but for this use-case it is unnecessary.

Chris

Re: bytecode interceptors

[Jules Gosnell <ju...@coredevelopers.net>]

James Strachan wrote:
> Saw this in the blogosphere today...
> 
> http://kasparov.skife.org/blog/2003/12/01#thank-you-chris
> 
> thought it looked interesting.  I wonder if we could look at integrating 
> this kind of feature ('baking' an interceptor stack into bytecode)

I've given this some thought...

I see three approaches with respective pros/cons...

1. Fully Dynamic - the current (as I understand it) approach

pros:

it's the most flexible

cons:

it's complex
it's dynamic (with associated overheads)


2. Aspected (requiring weaving at ClassLoading time)

pros :

much simpler - boilerplate is delegated to the Aspect community
it's static - should be faster and use less memory

cons:

possibly less flexible (it would be awkward to have an interceptor that 
changed it's stack's target object - although this could be achieved 
with the addition of a single layer of wrapping - maybe via (3)).


3. Just-in-time interceptor-baking :-)

pros :

preserves flexibility of (1)
interceptors could be baked with static interfaces, faster
there might be opportunities to bake an optimised stack to reduce the 
number of objects used.

cons :

probably the most complex solution....


Personally, I favour the Aspect approach. If this proved a little 
inflexible it could be augmented with one of the other approaches as and 
when necessary. The Aspect community have put a lot of work into this 
area and I think that Geronimo interceptors could benefit from this. My 
only concern is that aspects are currently not standardised. This makes 
picking a particular impl a risk.


Jules


> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 


-- 
/**********************************
  * Jules Gosnell
  * Partner
  * Core Developers Network (Europe)
  **********************************/