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
|