View source for JavaScript:SpiderMonkey:Arena Allocation

The SpiderMonkey arena allocation API is used for:

* Stack space in the JSContext (to be removed by [https://bugzilla.mozilla.org/show_bug.cgi?id=540706 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 ===

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

'''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]