Subj : Re: Newbie question. GC or memory managment.
To   : J.P.
From : Brendan Eich
Date : Fri Aug 27 2004 07:42 pm

J.P. wrote:
> Thanks for the responses. Espicially Brendan. You have been very patient.
> 
> During the past a few day's reading, i have seen several notes talking 
> about "racing with GC". My understanding is:
> 
> Given following code:
> 
> JS_BeginRequest(ctx);
> DoSomething();
> JS_EndRequest(ctx);
> 
> If DoSomething() takes too long, the GC will never get a chance to run, 
> right?


It will run only if DoSomething calls it, perhaps indirectly (via the 
branch callback, or if you hit out-of-memory from malloc, or if you hit 
the JS_NewRuntime parameter that bounds GC-things live in a runtime, via 
an attempt to allocate a GC-thing).

It's not a good idea to take too long in a request in general, whether 
or not the GC is starved.  You should JS_SuspendRequest before any long 
computation, first ensuring that all GC-things you may have created are 
well-rooted or otherwise connected to the live-thing graph; and of 
course JS_ResumeRequest after. Same for any blocking i/o or 
synchronization operation.


> In my code:
> 
> ctx = JS_NewContext();
> JS_BeginRequest(ctx);
> DoSomething();
> JS_EndRequest(ctx);
> ctx = JS_DestroyContext(ctx);
> 
> I sololy depend on the JS_GC() invoked by JS_DestroyContext(). Is it 
> safe to assume that all memory associated with that ctx will be released 
> properly?


The GC will collect garbage, independent of "associated with that ctx". 
  A JSContext is manually allocated, of course, so you have destroy it, 
and destroy does free all the manually allocated things associated with 
a context.

GC operates on the runtime's heap, and there are potentially many 
contexts in a runtime.  A context should not be thought of as a locus of 
storage.  It's an execution vehicle, an interpreter stack and virtual 
machine registers, and a few GC roots-by-definition.


> Actually, since the ctx was used only by one thread, i was wondering if 
> JS_BeginRequest() and JS_EndRequest() are necessary.


A JSContext is *always* used by only one thread at a time.  If you were 
to use a particular context concurrently from two or more threads, you'd 
face bad crash and deadlock bugs, and assertions.

You need requests in a multi-threaded embedding to interlock with the 
GC, and to help optimize object locking to almost lock-free cost.

/be

.