cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: Brakes (was: [control flow] changes and new sample)
Date Sun, 15 Sep 2002 04:08:34 GMT
Hi Tim,

On Friday, September 13, 2002, at 04:21  AM, Tim Coninx wrote:

> On Wed, Sep 11, 2002 at 04:48:42PM +0200, Sylvain Wallez wrote:
>> Tim Coninx wrote:
>>
>> We are *very serious* at using something like Brakes in Cocoon. The 
>> use
>> case is however a little bit different than Brakes : we want to
>> implement continuations, which are the capability for a program to
>> interrupt itself and be resume later in the state where it was
>> interrupted. The main difference (as far as I understand) with Brakes 
>> is
>> that program interruption is not triggered externally in our case.
>
> Actually, this was the main reason brakes was developed. Correlate was 
> a
> project exploring the concept of 'Active Objects', object that repeat a
> certain autonomous behaviour.
> The main difficulty here was that a separate scheduler from the one the
> JVM offers had to be used, to gain control of the scheduling of the
> active objects opposed to the core system.
>
> The first version of Brakes (which didn't have a name at that point)
> required every active object to Yield (effectively calling his own
> overridden yield method). This method would set the state of the active
> object to 'saving' and make the instrumented bytecode return every
> method in the call trace, while saving every stackframe. When the 
> active
> object is rescheduled, the state is set to restoring, and the call 
> trace
> rebuilds up to the point where the yield method was called, at which
> point the state is set back to normal. Then the next instruction (the
> one following the yield method) is called.

Very clever idea, I like it!

Are the bytecodes instrumented when the state is to be captured, and 
then recreated when the state is restored?

I imagine the state is captured in some sort of object, which is the 
equivalent of a continuation. Could you serialize this object to disk 
to free up memory?

> This version, which is much faster (or less slow ;-) than the last 
> version,
> is called brakes-serial (as opposed to brakes-parallel), and is 
> included
> in the main brakes release.

How slow was it compared to normal Java code? Especially in the 
presence of JIT in recent JDKs.

>>
>>> About licensing: because Brakes was abandoned so early, it is covered
>>> under the same proprietary license as it's parent project, Correlate
>>>       http://www.cs.kuleuven.ac.be/~distrinet/projects/CORRELATE/
>>>
>>> However, (again when you are serious about using brakes into Cocoon) 
>>> it
>>> will be possible to decouple Brakes from Correlate and embed the
>>> subproject (Brakes) into Cocoon, or at least release it seperately 
>>> under
>>> the APL.
>>>
>>
>> We would be *very interested* in that. Is some license change possible
>> so that we can at least look at the source code ?
>
> I'll start the administrative procedures (getting in touch with the
> group leader) now. In the mean time, I'll send you (personally) the
> source, so you can have a first look at it.

Thanks for taking the hassles!

Regards,
-- 
Ovidiu Predescu <ovidiu@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, 
Emacs ...)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message