Re: Clearing out temporary variables

["Victor J. Orlikowski" <vj...@dulug.duke.edu>]

On Fri, Jan 03, 2003 at 07:33:28PM -0500, Howard M. Lewis Ship wrote:
> With luck, in a non-heavily loaded application, there may just be one
> instance of BSFManager floating around.  In a worst case scenario, there
> could be many instances operating concurrently.  Is BSF, used in this way,
> threadsafe?
> 
Apologies for the *exceedingly* late reply.
Multiple BSFManagers with a classloader should be threadsafe.

> How well does BSF + Jython handle declareBean() and undeclareBean()?  My
> code declares three beans before invoking exec(), then undeclares them
> afterwards.  Again, I'm serializing access to the BSFManager.
> 
Not quite sure what you are asking here.

> Another thing I've noticed is that successive invocations of scripts are
> cumulative. i.e.:
> 
> bsf.exec("jython", "Inline", 0, 0, "i = 20");
> bsf.exec("jython", "Inline", 0, 0, "print i");
> 
> Will print 20 to the console.  The i variable, created in the first script,
> retains state for the second script.
> 
Correct. The BSFManager caches loaded scripting engines.

> Since the same BSFManager/BSFEngine instances will be reused in other
> contexts within the application, it seems that it would be possible that
> there would be side-effects, based on which scripts executed in which order
> against a particular BSFEngine.
> 
Correct. A logical addition to the BSFManager API seems to me to
be an unloadScriptingEngine and a resetScriptingEngine (to unload
and clear state, respectively).

> How expensive is creating new BSFManager instances?  I noticed that my first
> execution of a particular script took about 1700ms, but a subsequent
> execution of the same script (using same BSFManager) took only 10-20ms.
> 
BSFManager, not very.
Language engine, depends.
The speed of execution on the second execution is due to the
cached engine in the already loaded BSFManager.

> I just changed my code and reran.  The timings were almost identical when I
> didn't pool the BSFManager, but just created a new instance before execution
> and terminate() after.  Any idea how well that would scale?
> 
Probably pretty poorly, although the JVM may make instantiating
the language engine cheaper by caching it after the first instance
of doing so.

The dominating factor in the speed is the loading of the language
engine and (even more so) the execution of the script within it.

Victor
-- 
Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
==================================================================
orlikowski@apache.org  | vjo@dulug.duke.edu | vjo@us.ibm.com

RE: Clearing out temporary variables

["Howard M. Lewis Ship" <hl...@attbi.com>]

> 
> On Fri, Jan 03, 2003 at 07:33:28PM -0500, Howard M. Lewis Ship wrote:
> > With luck, in a non-heavily loaded application, there may 
> just be one 
> > instance of BSFManager floating around.  In a worst case scenario, 
> > there could be many instances operating concurrently.  Is 
> BSF, used in 
> > this way, threadsafe?
> > 
> Apologies for the *exceedingly* late reply.

You must have been busy on something.

> Multiple BSFManagers with a classloader should be threadsafe.
> 
> > How well does BSF + Jython handle declareBean() and 
> undeclareBean()?  
> > My code declares three beans before invoking exec(), then 
> undeclares 
> > them afterwards.  Again, I'm serializing access to the BSFManager.
> > 
> Not quite sure what you are asking here.
> 
> > Another thing I've noticed is that successive invocations 
> of scripts 
> > are cumulative. i.e.:
> > 
> > bsf.exec("jython", "Inline", 0, 0, "i = 20"); bsf.exec("jython", 
> > "Inline", 0, 0, "print i");
> > 
> > Will print 20 to the console.  The i variable, created in the first 
> > script, retains state for the second script.
> > 
> Correct. The BSFManager caches loaded scripting engines.
> 
> > Since the same BSFManager/BSFEngine instances will be 
> reused in other 
> > contexts within the application, it seems that it would be possible 
> > that there would be side-effects, based on which scripts 
> executed in 
> > which order against a particular BSFEngine.
> > 
> Correct. A logical addition to the BSFManager API seems to me 
> to be an unloadScriptingEngine and a resetScriptingEngine (to 
> unload and clear state, respectively).
> 
> > How expensive is creating new BSFManager instances?  I 
> noticed that my 
> > first execution of a particular script took about 1700ms, but a 
> > subsequent execution of the same script (using same 
> BSFManager) took 
> > only 10-20ms.
> > 
> BSFManager, not very.
> Language engine, depends.
> The speed of execution on the second execution is due to the 
> cached engine in the already loaded BSFManager.


Basically, under this scenario, a pool of engines would be shared by
a large number of clients; it would not be deterministic which clients would
make use of which engines to execute the scripts.  This is the nature of distributed
web  applications.

Side effects could be quite deadly.

Ideally, I could pool the engines, but clear them out (of variables, etc.) between uses.


> 
> > I just changed my code and reran.  The timings were almost 
> identical 
> > when I didn't pool the BSFManager, but just created a new instance 
> > before execution and terminate() after.  Any idea how well 
> that would 
> > scale?
> > 
> Probably pretty poorly, although the JVM may make 
> instantiating the language engine cheaper by caching it after 
> the first instance of doing so.

For single user testing it worked well.  I think what I was getting at is that
the initial startup time for creating the first manager was pretty steep ...
but that involved a lost of class loading (BSF, Jython) and the other Jython
initialization magic.

Outisde of that one-time cost, executing the scripts didn't seem to cost much.



> 
> The dominating factor in the speed is the loading of the 
> language engine and (even more so) the execution of the 
> script within it.

I think BSF managers and/or engines should be poolable, in the way that databsae connections
are poolable.  This involves being able to reset the engine to a known state.  I suspect
the original pupose of BSF was to support scripting in a single-threaded, or rich client,
environment and I realize I'm trying to repurpose it for a multi-threaded web environment.


In the meantime, Tapestry has the feature for using BSF/Jython, but I honestly don't know how good
this feature will work in production.  I'd love to mention it more in the book I'm writing
("Tapestry
in Action", for Manning) but don't feel safe doing so.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry