416719 - Investigate jsarena specialized release-at-once structures

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement, P5)

Description

[Igor Bukanov]

Currently the parser and the emitter use the arenas to allocate parse nodes and emitter's data. The allocated memory is not released until parsing or emitting is finished. As such using the generic data structure implementing LIFO mark/release is not necessary and may add an extra overhead.

It would be nice to use in the compiler an alternative data structure supporting just allocations and release-when-done with growth strategies better suited for parser/emitter.

Comment 1

[Robin Bate Boerop]

http://lxr.mozilla.org/seamonkey/ident?i=JS_ARENA_RELEASE

The above shows the callers who make use of marks in arenas.  Igor, are you saying that those callers are not really using the marking logic?  Or, just some of them?

The mark/release overhead is only paid by callers (who have to retain the mark), and in JS_ArenaRelease.  The overhead in that function is negligible.  So, the arena code, as-is, is exactly the desired "just allocations and release-when-done" thing.

As to the growth strategies - if they need to be tuned, then that's something worth investigating.

Comment 2

[Igor Bukanov]

(In reply to comment #1)
> http://lxr.mozilla.org/seamonkey/ident?i=JS_ARENA_RELEASE
> 
> The above shows the callers who make use of marks in arenas.  Igor, are you
> saying that those callers are not really using the marking logic?  Or, just
> some of them?

My observation is that the parser and the emitter needs to allocate a lot of fixed-sized things of few different sizes like JSParseNode etc. All these allocations are released at once when code generation is done.

It would be nice if the code can take advantage of the fact that there is no oversized allocations. Moreover, allocating fixed-sized arenas in this case is suboptimal and an exponential growth strategy would lead to less allocations.  

> 
> The mark/release overhead is only paid by callers (who have to retain the
> mark), and in JS_ArenaRelease.  The overhead in that function is negligible. 
> So, the arena code, as-is, is exactly the desired "just allocations and
> release-when-done" thing.
> 
> As to the growth strategies - if they need to be tuned, then that's something
> worth investigating.
> 

Comment 3

[Nicholas Nethercote [inactive]]

I'm going to close this, due to a lack of profile data showing that it's actually a problem.  If such data is found, I think increasing the tempPool arena size from 4KB to 16KB would be a dead-easy way to improve things.