Subj : Re: JS_AddNamedRoot() and finalizer To : netscape.public.mozilla.jseng From : Matthew Mondor Date : Thu Aug 26 2004 02:28 pm On Thu, 26 Aug 2004 09:48:40 -0700, Brendan Eich wrote: > > A slab-like allocator will be used to manage a pool of processes and > > associated JS contexts, and this means that the pool of processes must be > > reusable to execute multiple scripts each without them necessarily destroying > > the context. I would like js_context_reset() to be enough to ensure that it is > > possible to reuse the process and thus it's associated context often. The code > > to destroy the context and runtime would only be called when it is considered > > that the process is extraneous after statistics show that the server should be > > allowed to scale down a bit. > > > This is all do-able with existing JS API, and multi-threaded embeddings > do it often (pool contexts and threads, mapping them 1:1 for recycling). > > You do mean thread, not process, right? Otherwise, adderess spaces are > disjoint and there's no sharing of any data. I actually mean processes (the target application does not use threads but a pool of proceses somewhat like apache does, since it has to occasionaly use features such as execve(2) which is problematic with threads, additionally we need privilege separation between them)... However, each process will concurrently execute one script at a time. However, every process must also be ready to execute another script as soon as possible after it ends executing one. By shared in this context I meant between multiple consecutive script executions rather than concurrent ones. This is why it is also important for me to be able to efficently "reset and recycle" the previous context so that it may be reused without needing to be re-created if possible, and without allowing a previous script to pollute the context of the next one to execute... However, there will be a need for some shared resources and sychronization between processes, but this will be handled as necessary by custom properly or method handler functions... The framework of slab allocator and shared memory with related synchronization is already there in the application. > The runtime can be per-process. The only reason to have more than one > runtime per-process is to simulate multiple VMs. There are valid > reasons for multiple VMs in one process, but it's not clear to me you > have one yet. Yes in this case we only ever need one concurrent script execution per process anyways, so no need for multiple contexts per process, even less for multiple runtimes... > > I guess that as necessary I could have a few scealed classes for the "system" > > methods, a global shared one for some persistent properties among multiple > > execution (like current API's properties)... > > > Yeah, sealing (which requires a throwaway or special context if you pass > JS_TRUE for the "deep" parameter) will keep anything in the sealed > object graph from changing. But do you want a global that's read/write > to be shared among threads? That sounds like a recipe for name > collisions and race conditions, at the JS level, even if the engine's > JS_THREADSAFE code keeps its data structures coherent and correct. In this case, probably that as long as methods and properties which shared resource among multiple processes ensure to use proper synchronization, and keeping those shared resources opaque to SpiderMonkey, that it will be safe? Perhaps that this is where adding root for some custom-allocated objects not tied to the SM context objects might become handy also... But as long as I can have a user pointer to data tied to a JSObject (and this seems possible using the API) I should be able to work out the refcount and synchronization in the methods/properties which need some shared resources without allocating additionnal JS objects for it internally, that memory has to be shared anyways and thus allocated from a shared memory pool rather than using the process heap... BTW, I started writing some SpiderMonkey documentation (latex book format, although quite summary for now still, and mostly made for my own use, I might perhaps publish it under an open documentation license later on, and try to fill in the gaps I found when reading the various tutorials and examples I could find via the mozilla site links)... Ideally it would be documenting as much as possible the obscure areas which we often see questions on this list about, GC issues, thread concurrency and scope issues, when to use seal and when/why to tie objects to root, etc... Of course quality of result will depend on my free time, but I believe that I'll be using SM in the future for various other projects too. I'm archiving the interesting posts on this list which I find useful to help me learn better in those areas, for later review, so I can write proper docs on it also, but of course I might ask some more questions about techical details I don't yet grasp from time to time.. Thanks again, Matt .