637216 - JM: remove manual refcounting of ExecutablePools

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

ExecutablePools have manual refcounting.  This is error-prone, see bug 635968.  We should change it to something less error-prone.  I see two options.

1. Automatic refcounting with a smart pointer class.  It's the "right" (sophisticated) way to do it, and would allow memory to be freed as soon as possible.

2. Manual management.  This is the worse-is-better approach and it will only be suitable if there are a small number of lifetimes.  AFAIK we have the following lifetimes:

- PICs are purged every GC
- MICs are purged on GCs if shape regeneration has occurred
- Other JM code is purged when a compartment dies

That points to two basic lifetimes, PIC and non-PIC (I'm assuming shape regeneration is rare enough that MICs could go in with normal code without causing much fragmentation, though I could be wrong about that).  Bug 631045 is a step in the right direction for this (and worth doing even if we go with auto-refcounting, due to reduced fragmentation).  But then there's bhackett's half-life purging stuff, I don't know how that fits in.

Comment 1

[David Mandelin [:dmandelin]]

(In reply to comment #0)
> ExecutablePools have manual refcounting.  This is error-prone, see bug 635968. 
> We should change it to something less error-prone.  I see two options.
> 
> 1. Automatic refcounting with a smart pointer class.  It's the "right"
> (sophisticated) way to do it, and would allow memory to be freed as soon as
> possible.

I think this is important but not urgent, so the "right" way seems best.

Comment 2

[Nicholas Nethercote [inactive]]

(In reply to comment #1)
> 
> I think this is important but not urgent, so the "right" way seems best.

It's definitely important.  Urgency isn't a factor in the choice between (1) and (2), but I deliberately put "right" in scare quotes... http://en.wikipedia.org/wiki/Worse_is_better.  I favour (2) if there are a small number of lifetimes.

Comment 3

[Nicholas Nethercote [inactive]]

Another thing in favour of (2):  we currently have an ExecPoolVector in each PIC (in BasePolyIC, to be specific).  With approach (2) we wouldn't need this, and so we'd save one word per PIC.

Comment 4

[Jan de Mooij [:jandem]]

Baseline/Ion use GC-allocated IonCode objects, refcounting is handled when constructing/finalizing these objects.