JavaScript:SpiderMonkey:Arena Allocation: Difference between revisions
(Arena allocation info and plans.) |
(→Plans: Added (presumably bad) estimates.) |
||
| Line 9: | Line 9: | ||
=== Plans === | === Plans === | ||
{| width="80%" cellspacing="1" cellpadding="6" border="0" | |||
|- | |||
! scope="col" | Name | |||
! scope="col" | Size (weeks) | |||
|- | |||
| Soft release | |||
| 1 | |||
|- | |||
| Chunk policy | |||
| 0.5 | |||
|} | |||
'''Time-deferred "soft" release''' — it was observed in the execution of imacro_asm.js that the regexp pool thrashes quite a bit: a recurring free/alloc of a single arena occurs with each simple regular expression match. By sticking a timestamp on the arena pool and having the garbage collector release the outstanding arenas at a later time we can avoid this overhead in the common case. | '''Time-deferred "soft" release''' — it was observed in the execution of imacro_asm.js that the regexp pool thrashes quite a bit: a recurring free/alloc of a single arena occurs with each simple regular expression match. By sticking a timestamp on the arena pool and having the garbage collector release the outstanding arenas at a later time we can avoid this overhead in the common case. | ||
'''Determine optimal arena chunk policy''' — the arena chunk sizes should mesh with the virtual memory subsystem as nicely as possible. For example, mallocing PAGE_SIZE + 1 byte is probably not ideal. It appears that OS X and Linux follow the same allocation patterns with their malloc implementations WRT their page sizes from [http://bitbucket.org/cdleary/vmem-chunk-allocation/src these experiments]. Further investigation would probably be helpful in determining an overall policy. References: [https://bugzilla.mozilla.org/show_bug.cgi?id=421435 421435], [https://bugzilla.mozilla.org/show_bug.cgi?id=561286 561286] | '''Determine optimal arena chunk policy''' — the arena chunk sizes should mesh with the virtual memory subsystem as nicely as possible. For example, mallocing PAGE_SIZE + 1 byte is probably not ideal. It appears that OS X and Linux follow the same allocation patterns with their malloc implementations WRT their page sizes from [http://bitbucket.org/cdleary/vmem-chunk-allocation/src these experiments]. Further investigation would probably be helpful in determining an overall policy. References: [https://bugzilla.mozilla.org/show_bug.cgi?id=421435 421435], [https://bugzilla.mozilla.org/show_bug.cgi?id=561286 561286] | ||
Latest revision as of 23:22, 27 April 2010
The SpiderMonkey arena allocation API is used for:
- Stack space in the JSContext (to be removed by bug 540706)
- Temp space in the JSContext
- Bytecodes/source notes in the js::Compiler for expanding compilation storage
- JSScopeProperties in the JSPropertyTree objects
- Temp space for regular expression matching, stored in the JSContext
- Decompiler printer objects
Plans
| Name | Size (weeks) |
|---|---|
| Soft release | 1 |
| Chunk policy | 0.5 |
Time-deferred "soft" release — it was observed in the execution of imacro_asm.js that the regexp pool thrashes quite a bit: a recurring free/alloc of a single arena occurs with each simple regular expression match. By sticking a timestamp on the arena pool and having the garbage collector release the outstanding arenas at a later time we can avoid this overhead in the common case.
Determine optimal arena chunk policy — the arena chunk sizes should mesh with the virtual memory subsystem as nicely as possible. For example, mallocing PAGE_SIZE + 1 byte is probably not ideal. It appears that OS X and Linux follow the same allocation patterns with their malloc implementations WRT their page sizes from these experiments. Further investigation would probably be helpful in determining an overall policy. References: 421435, 561286