On Sat, Apr 2, 2011 at 6:56 AM, Anthony Catel <[email protected]> wrote:
> Hi Doug,
>
> I've been running the test during 12 hours with :
>
> - 4 users connected
> - 5 messages second (with your script running in a while(1){sleep(1) }).
>
> It still working but take 0.4% on my 6GB memory (which is may be not
> normal).
>
> Anyway, the problem may be a garbage collection issue with the javascript
> engine.
> I'll do more test this night (more user, more messages) ;)
>
- ensure you are building --enable-threadsafe so that you get the benefit
of background-thread finalization etc
- run a second thread in another context of the same compartment and use
this to call JS_MaybeGC() on a timer (GPSEE uses a 2-second timer IIRC)
- ensure all your code in libape_spidermonkey.c which can possibly block
(any I/O calls, especially into mysql, read/write sockets, files, etc) are
surrounded with JS_SuspendRequest()...JS_ResumeRequest() calls
- ensure that you do not leave active contexts "floating" -- either end
them, destroy them, or suspend them
If you follow these approaches, you will be able to do opportunistic GC,
where the likelihood that you run your GC on one thread while another is in
I/O increases dramatically. So, you will run many short GC runs
(hopefully!) instead of rarely running GC when you have exceeded the trigger
factor.
IIRC, the default trigger factor is for the JS heap to have increased to 16
times the size it was the last time you GC'd. You can adjust this with
JS_SetGCTriggerFactor()(? -- IIRC) for JS 1.8.2, or JS_SetGCParameter(rt,
JSGC_TRIGGER_FACTOR, value) for JS 1.8.5.
Do not set the trigger below 200 (meaning 200% heap growth) because a bug in
the way the trigger is evaluated in jsgc.cpp will cause the same behaviour
as JS_SetGCZeal(cx, 1) and kill you on perf.
You can see what's taking up your memory with JS_DumpHeap. This works best
in a debug build, and IIRC, if you have good JSClass::name, and also, if you
name your GC roots.
The key to keeping your heap size down is to use as little JS memory as
possible (obviously!), ensuring that you don't leave things like giant
closures lying around as props of the global variable but unused. That is
for the JS coder.
>From the C side, we must make sure we run the garbage collector fairly
often. The opportunistic GC algorithm I described works because JSAPI uses a
stop-the-world GC based on a mutex rendezvous, where the GC-initiating
thread waits on the mutex until all other active contexts have reported that
they are waiting for that thread to mark/sweep the roots. This is why we
call JS_MaybeGC() frequently and suspend around system calls -- the other
thread waiting will mark/sweep as soon as the busy context suspends, then
hopefully finishes before the system call so the GC was zero-cost. Then
finalization (free) occurs in yet another thread.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
--
You received this message because you are subscribed to the Google
Groups "APE Project" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/ape-project?hl=en
---
APE Project (Ajax Push Engine)
Official website : http://www.ape-project.org/
Git Hub : http://github.com/APE-Project/
