Subj : Re: Implementing Resource Control in Spider Monkey
To   : netscape.public.mozilla.jseng
From : sajidraza@hotmail.com (S. Raza)
Date : Fri Mar 12 2004 04:56 pm

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).

> 
> Are you talking about scripts calling scripted functions where the 
> scripted functions should be subject to a different qouta from the 
> calling script (or calling scripted function)?
> 

The user defined script / calling scripted function needs to be
metered along with any functions that it may call.

> > might be too
> >much. I'm thinking about intercepting calls to JS_NewObject. Would
> >that be reasonable?
> >  
> >
> 
> Not really -- how much memory does an object take?  Even the crude 
> JSRuntime-based accounting doesn't try to guess.

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.

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.

> 
> Your best bet for now is to use a JSRuntime per thread pooling approach, 
> from what I can tell.
> 
> >Secondly for CPU usage, the js_Interpret function seems to be a nice
> >place to inject any CPU usage checks. Basically for let the
> >interpreter execute for N ops, and then check the elapsed 'real' CPU
> >usage for the process each time. The other possibility as in JSEAL is
> >to re-write byte-code to enable call-backs into CPU usage checking
> >code after executing some block of code.
> >
> 
> Just use JS_SetBranchCallback and be happy.  I doubt straight-line code 
> will be able to consume much CPU, unless you let people generate 
> megabytes of straight-line code from perl scripts, e.g.

Sounds good to me.

> What kind of trust model do you have here, anyway?  If you're worried 
> about resource quotas, what else are you worrying about bad or confused 
> users doing?

The trust model boils down to no trust. User scripts are resource
controlled. Any primitives (exposed through JS objects) user-scripts
might utilize are also resource controlled.

I understand that re-using runtimes is a clear and viable method, but
I just wanted to explore all possibilities.

Thanks,

Raza

.