Subj : Re: Implementing Resource Control in Spider Monkey To : "S. Raza" From : Brendan Eich Date : Fri Mar 12 2004 05:13 pm S. Raza wrote: > Thanks for responding. I thought I'd do some background reading before > posting again. > > >>Why wouldn't you reuse JSRuntimes, pool them one-to-one with threads? > > > The application is hosting multiple scripts that need to be resource > controlled individually. Associating a run-time per thread might be an > issue (I'll have to investigate further), as I have little control > over how threads are created or how many exist (this is going to be an > extension to Apache). You can surely get the current thread id. With it, you can maintain a hashtable/lru-list pool of runtimes, where active runtimes (in use by threads) are in the hashtable but not on the lru-list, hashed by thread id key. Inactive runtimes stay associated by thread-id in the hashtable but are also on the lru-list, liable to be recycled for another thread. You can cap the maximum number of runtimes pooled this way, while overallocating if demand exceeds the max pool population. > Point well taken. From what I can tell, it seems that the amount of > memory allocated depends on the sizeof(GCThing) plus the amount of > memory allocated to slots for properties for a particular object, or > the string associated with a jsstring etc. I guess it would be > possible to intercept each of these allocations and charge them to a > per-runtime associated quota. JSScopes are shared among objects, potentially (prototype and unmutated delegating newborn instances), and JSScopeProperties are shared aggressively via rt->propertyTreeHash (see jsscope.h). So don't overcharge! > As a side question, is there any place where the gcMallocBytes field > of a JSRuntime struct is incremented, but never decremented? After an > object, string, or jsdouble finalizer is executed and memory > reclaimed wouldn't it be appropriate to decrement this value. The same > seems to be true for gcBytes. I might have it wrong, but I thought I'd > ask. gcMallocBytes is zeroed after GC. It's a cheesy heuristic added years ago by some server guys at a company Netscape bought. I've been too busy elsewhere to rip it out, or rationalize it. Maybe with your help that can happen now. /be .