Investigate jsarena specialized release-at-once structures

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
P5
enhancement
RESOLVED WONTFIX
10 years ago
7 years ago

People

(Reporter: Igor Bukanov, Assigned: Robin Bate Boerop)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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.
(Assignee)

Comment 1

10 years ago
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.
(Reporter)

Comment 2

10 years ago
(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.
> 

(Assignee)

Updated

10 years ago
Assignee: general → moz
Priority: -- → P5
Summary: Specialized release-at-once structures → Investigate jsarena specialized release-at-once structures
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.