Subj : Re: Problem with the Garbage Collector To : Zaph From : Brendan Eich Date : Mon Mar 08 2004 01:27 pm This is a multi-part message in MIME format. --------------080709040407080308010406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Zaph wrote: >Brendan Eich wrote in message news:<4048D12D.80300@meer.net>... > > >>Zaph wrote: >> >> >>>Unfortunately I cannot change the way the scripts are being started >>>and it is possible that one script may run for days. >>> >>> >>Days? Doing what? Computing Pi to the last digit? ;-) >> >> > >I am check the status of several machines (each with its own script). > > Then you must be calling native methods that do blocking i/o, or otherwise take long enough that they should suspend requests on their context. >>Surely your scripts are calling native methods, some of which do i/o, >>possibly even blocking i/o. The rule you are failing to follow is that >>every such native must suspend requests on its cx parameter, resuming >>them after it returns from the blocking call. >> >> > >Could you explain this a little more in detail ? > > What's to explain? You have a native method or getter/setter that blocks: JSBool my_native(JSContext *cx, JSObject *obj, ...) { jsrefcount savDepth; /do stuff that runs to completion very quickly, without blocking/; saveDepth = JS_SuspendRequest(cx); /call blocking i/o or similar long-running code here/; JS_ResumeRequest(cx, saveDepth); /do more non-blocking stuff and return/; } >>Good, but you're not following all the of the request model's rules. >> >> > >And what are the request model's rules ? > > 1. Call JS_BeginRequest and JS_EndRequest around every maximal non-blocking batch of API calls and native code. 2. Call JS_SuspendRequest before making a blocking call or otherwise executing long-running native code, and JS_ResumeRequest after such call/code. 3. Call JS_GC or JS_MaybeGC on a background thread every now and then, and more often from native code that knows it has created garbage. 4. Never hold locks while calling into another module (including making any JS API calls). >>>Is there a way to start the Garbage Collector while the scripts are >>>active >>> >>> >>Not "active" in the sense of "in a request", no. That's by design, >>that's why you need to suspend or end requests often. >> >> >Could I use a different runtime environment for each script to bypass >this problem ? > > No. Why would you do that instead of fixing your embedding to follow the request model's rules? >When the runtime runs out of memory to compile the scripts it just >goes into a infinit loop. Is there a way to compile it safely ? > > Where is this infinite loop? Show some stack samples, if not an actual loop in the code. /be --------------080709040407080308010406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Zaph wrote:

Brendan Eich <brendan@meer.net> wrote in message news:<4048D12D.80300@meer.net>...

Zaph wrote:

Unfortunately I cannot change the way the scripts are being started
and it is possible that one script may run for days.

Days?  Doing what?  Computing Pi to the last digit? ;-)


I am check the status of several machines (each with its own script).

Then you must be calling native methods that do blocking i/o, or otherwise take long enough that they should suspend requests on their context.

Surely your scripts are calling native methods, some of which do i/o, 
possibly even blocking i/o.  The rule you are failing to follow is that 
every such native must suspend requests on its cx parameter, resuming 
them after it returns from the blocking call.


Could you explain this a little more in detail ?

What's to explain? You have a native method or getter/setter that blocks:

JSBool my_native(JSContext *cx, JSObject *obj, ...) { jsrefcount savDepth; do stuff that runs to completion very quickly, without blocking; saveDepth = JS_SuspendRequest(cx); call blocking i/o or similar long-running code here; JS_ResumeRequest(cx, saveDepth); do more non-blocking stuff and return; }

Good, but you're not following all the of the request model's rules.


And what are the request model's rules ?

1. Call JS_BeginRequest and JS_EndRequest around every maximal non-blocking batch of API calls and native code.

2. Call JS_SuspendRequest before making a blocking call or otherwise executing long-running native code, and JS_ResumeRequest after such call/code.

3. Call JS_GC or JS_MaybeGC on a background thread every now and then, and more often from native code that knows it has created garbage.

4. Never hold locks while calling into another module (including making any JS API calls).

Is there a way to start the Garbage Collector while the scripts are
active

Not "active" in the sense of "in a request", no.  That's by design, 
that's why you need to suspend or end requests often.

Could I use a different runtime environment for each script to bypass
this problem ?

No.

Why would you do that instead of fixing your embedding to follow the request model's rules?

When the runtime runs out of memory to compile the scripts it just
goes into a infinit loop. Is there a way to compile it safely ?

Where is this infinite loop? Show some stack samples, if not an actual loop in the code.

/be --------------080709040407080308010406-- .