You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Coninx <ti...@cs.kuleuven.ac.be> on 2002/09/11 13:48:35 UTC
Brakes (was: [control flow] changes and new sample)
Hello,
As I was pointed by a friend to the previous thread, I noticed a
proposal to prototype Brakes, which I have been working on a time ago.
This is not a commercial message, but a status report of the technology.
Brakes consists of two parts:
- A bytecode transformer adds bytecode after every method start,
and before every method call.
The bytecode before each method call makes sure the control flow of
the executing thread gets saved.
The bytecode at the start of each method checks the state of the
thread, and acts upon that (normal/saving/restoring)
- A small experimental framework which serves as a starting point for a
thread, a place in which the control flow gets saved, and the point
from which the control flow gets restored.
The research on brakes is being discontinued, partly because too few
people worked on it, partly because we (I) didn't had the nerve to get
this project into a more serious prototype stage.
The code however exists, and is usuable to certain extent.
The biggest problem is the bytecode transformer. This is a huge piece of
work by Bert Robben, a member of our research group who left four years
ago. We suspect he is the only one with full understanding about the
transformer.
A positive thing is that the transformer is based on BCEL (the bytecode
engineering library) by Markus Dahm. (During that time named JavaClass).
BCEL is still under development, now under the wings of Jakarta
http://jakarta.apache.org/bcel/
I am pretty sure that much of the 'difficult' functionality in the
transformer is now handled within the BCEL. So a rewrite of the
transformer /should/ be feasible.
The framework part is of course something that should be redesigned to
fit on Cocoon.
The past weeks, I have been looking again at BCEL, and have been
gathering ideas about how to redesign the bytecode transformer. When
you are serious about using Brakes in Cocoon, I am of course willing
to devote a great deal of time in helping with the transformer and the
framework's integration in Cocoon.
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.
Oh, I am new to this list, so forgive me if I broke some rules.
Anyhow, let's hear what you think
--
Tim Coninx -*- KULeuven Department of Computer Science
http://www.cs.kuleuven.ac.be/cwis/research/distrinet/public/index.php
gpgkey @ http://www.cs.kuleuven.ac.be/~tim/
ICMP: The protocol that goes PING!
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Tim Coninx wrote:
>Hello,
>
>On http://www.cs.kuleuven.ac.be/~tim/MOS/brakes.html Brakes 0.3 is
>available.
>
>The big change is off course the license change.
>
>Happy downloadin' an' codin'
>
>
Way cool ! Thanks a lot, Tim.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Tim Coninx <ti...@cs.kuleuven.ac.be>.
Hello,
On http://www.cs.kuleuven.ac.be/~tim/MOS/brakes.html Brakes 0.3 is
available.
The big change is off course the license change.
Happy downloadin' an' codin'
--
Tim Coninx -*- KULeuven Department of Computer Science
http://www.cs.kuleuven.ac.be/cwis/research/distrinet/public/index.php
gpgkey @ http://www.cs.kuleuven.ac.be/~tim/
VI VI VI The editor of the beast.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Tim Coninx <ti...@cs.kuleuven.ac.be>.
On Sat, Sep 14, 2002 at 09:08:34PM -0700, Ovidiu Predescu wrote:
> 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:
> >>
> >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.
At this time, I should point you to the research paper which was
presented at ASAMA (Agent System Applications and Mobile Agents) 2000 in
Zurich.
I know, I know, it is research language (meaning it doesn't get to the
point very quickly), but it has the answers to every question you asked.
You can get it here
http://www.cs.kuleuven.ac.be/~tim/MOS/MA2000Final.pdf
--
Tim Coninx -*- KULeuven Department of Computer Science
http://www.cs.kuleuven.ac.be/cwis/research/distrinet/public/index.php
gpgkey @ http://www.cs.kuleuven.ac.be/~tim/
Strike any user when ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Tim Coninx wrote:
>On Fri, Sep 13, 2002 at 02:43:18PM +0200, Sylvain Wallez wrote:
>
>
>>What can be the result of the administrative procedures you're talking
>>about ? Can we forsee a relicensing under the Apache licence ? If such
>>licensing is possible, what about considering a donation to the BCEL
>>project, as Brakes has a broader potential than Cocoon ?
>>
>>
>
>We will license Brakes under the Academic Free License
> http://www.opensource.org/licenses/academic.php
>
>This way, we'll still own the project, but you can use it as you like.
>
Great !
>I hope this is enough for you to integrate it into Cocoon without legal
>burden.
>
>
I'm not a lawyer, but it seems to me the Adacemic license is compatible
with the Apache license.
>Please allow a few days to make the changes and publish them.
>
No problem. You already did a great job and it was very fast.
>>And finally, is someone still working on Brakes, i.e. can we expect some
>>help from you or your group at least to get started ?
>>
>>
>
>No-one is currently working on Brakes, but the knowledge is still
>available here. Just contact me for help on Brakes, and I'll get the
>answer from someone ;-)
>
>
Thanks a lot.
>In any case, I'll try to work myself (slowly) into Cocoon and help out
>as much as possible.
>
>
Don't hesitate to ask if you encounter some problems.
Thanks a lot,
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Ovidiu Predescu <ov...@cup.hp.com>.
On Thursday, September 26, 2002, at 08:44 AM, Tim Coninx wrote:
> On Fri, Sep 13, 2002 at 02:43:18PM +0200, Sylvain Wallez wrote:
>>
>> What can be the result of the administrative procedures you're talking
>> about ? Can we forsee a relicensing under the Apache licence ? If such
>> licensing is possible, what about considering a donation to the BCEL
>> project, as Brakes has a broader potential than Cocoon ?
>
> We will license Brakes under the Academic Free License
> http://www.opensource.org/licenses/academic.php
>
> This way, we'll still own the project, but you can use it as you like.
>
> I hope this is enough for you to integrate it into Cocoon without legal
> burden.
Great work Tim, thanks a lot! I think it's enough too.
> Please allow a few days to make the changes and publish them.
Sure, let us know.
>> And finally, is someone still working on Brakes, i.e. can we expect
>> some
>> help from you or your group at least to get started ?
>
> No-one is currently working on Brakes, but the knowledge is still
> available here. Just contact me for help on Brakes, and I'll get the
> answer from someone ;-)
>
> In any case, I'll try to work myself (slowly) into Cocoon and help out
> as much as possible.
We'll also have to look slowly into Brakes as well ;)
Regards,
Ovidiu
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Tim Coninx <ti...@cs.kuleuven.ac.be>.
On Fri, Sep 13, 2002 at 02:43:18PM +0200, Sylvain Wallez wrote:
>
> What can be the result of the administrative procedures you're talking
> about ? Can we forsee a relicensing under the Apache licence ? If such
> licensing is possible, what about considering a donation to the BCEL
> project, as Brakes has a broader potential than Cocoon ?
We will license Brakes under the Academic Free License
http://www.opensource.org/licenses/academic.php
This way, we'll still own the project, but you can use it as you like.
I hope this is enough for you to integrate it into Cocoon without legal
burden.
Please allow a few days to make the changes and publish them.
> And finally, is someone still working on Brakes, i.e. can we expect some
> help from you or your group at least to get started ?
No-one is currently working on Brakes, but the knowledge is still
available here. Just contact me for help on Brakes, and I'll get the
answer from someone ;-)
In any case, I'll try to work myself (slowly) into Cocoon and help out
as much as possible.
CU
--
Tim Coninx -*- KULeuven Department of Computer Science
http://www.cs.kuleuven.ac.be/cwis/research/distrinet/public/index.php
gpgkey @ http://www.cs.kuleuven.ac.be/~tim/
Money is the root of all evil (Send $30 shareware fee to use this tag line.)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
>
>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.
>
>
>
>>>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.
>
>
Well received. Thank you very much, Tim. I will study this with great
interest.
What can be the result of the administrative procedures you're talking
about ? Can we forsee a relicensing under the Apache licence ? If such
licensing is possible, what about considering a donation to the BCEL
project, as Brakes has a broader potential than Cocoon ?
And finally, is someone still working on Brakes, i.e. can we expect some
help from you or your group at least to get started ?
Thanks for your answers, and of course for the sources.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Ovidiu Predescu <ov...@apache.org>.
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 <ov...@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
Re: Brakes (was: [control flow] changes and new sample)
Posted by Tim Coninx <ti...@cs.kuleuven.ac.be>.
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.
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.
>
> >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.
--
Tim Coninx -*- KULeuven Department of Computer Science
http://www.cs.kuleuven.ac.be/cwis/research/distrinet/public/index.php
gpgkey @ http://www.cs.kuleuven.ac.be/~tim/
665.9238429876 - Number of the Pentium Beast
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Brakes (was: [control flow] changes and new sample)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Tim Coninx wrote:
>Hello,
>
>As I was pointed by a friend to the previous thread, I noticed a
>proposal to prototype Brakes, which I have been working on a time ago.
>
>This is not a commercial message, but a status report of the technology.
>
>Brakes consists of two parts:
>- A bytecode transformer adds bytecode after every method start,
> and before every method call.
> The bytecode before each method call makes sure the control flow of
> the executing thread gets saved.
> The bytecode at the start of each method checks the state of the
> thread, and acts upon that (normal/saving/restoring)
>- A small experimental framework which serves as a starting point for a
> thread, a place in which the control flow gets saved, and the point
> from which the control flow gets restored.
>
>The research on brakes is being discontinued, partly because too few
>people worked on it, partly because we (I) didn't had the nerve to get
>this project into a more serious prototype stage.
>
>The code however exists, and is usuable to certain extent.
>
>The biggest problem is the bytecode transformer. This is a huge piece of
>work by Bert Robben, a member of our research group who left four years
>ago. We suspect he is the only one with full understanding about the
>transformer.
>A positive thing is that the transformer is based on BCEL (the bytecode
>engineering library) by Markus Dahm. (During that time named JavaClass).
>BCEL is still under development, now under the wings of Jakarta
> http://jakarta.apache.org/bcel/
>
>I am pretty sure that much of the 'difficult' functionality in the
>transformer is now handled within the BCEL. So a rewrite of the
>transformer /should/ be feasible.
>
>
Agree. I'm also using BCEL for class transformation, and I must say it
makes things relatively easy... once you master the virtual machine
specification !
>The framework part is of course something that should be redesigned to
>fit on Cocoon.
>
>The past weeks, I have been looking again at BCEL, and have been
>gathering ideas about how to redesign the bytecode transformer. When
>you are serious about using Brakes in Cocoon, I am of course willing
>to devote a great deal of time in helping with the transformer and the
>framework's integration in Cocoon.
>
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.
>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 ?
>Oh, I am new to this list, so forgive me if I broke some rules.
>
No problem. This was perfect. Welcome !
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org