913239 - Enable un-marking properties as CONFIGURED (a limited number of times)

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Till Schneidereit [:till]]

As per our IRC discussion, it should be possible to reset the CONFIGURED marking, because if it is set, property accesses can't do any optimizations that would require it to be stable, anyway.

To prevent endless recompilation loops of doom, this should be limited to a fixed number of flip-flops, maybe just one.

Comment 1

[Till Schneidereit [:till]]

Let's give this a summary that makes at least a modicum of sense.

Comment 2

[Brian Hackett [Laid off!]]

This sort of stuff didn't really fit with the pre-804676 version of TI, where there was a web of constraints and type information needs to grow (i.e. despecialize) monotonically.  However, now we're in a place where type constraints are really just used for triggering recompilation, and this restriction could be relaxed.  I guess the main question I have is, why do you want to do this?

Comment 3

[Eric Faust [:efaust]]

(In reply to Brian Hackett (:bhackett) from comment #2)
> I guess the main question I have is, why do you want to do this?

There is a now common trend amongst emulators (shumway and JSIL both make use) of "lazy properties". The idea is that you first install the property as a getter, which does a bunch of calculation/initalization of things and then uninstalls itself and leaves the value as a data property. The property then remains a data property forever after that. The problem we have encountered is that the CONFIGURED flag gets set when the getter is set, and then this is deeply deoptimizing when we come to jit-compile code involving that property, even though it will be slotful forever after that.

As this is a common idiom, this seemed like a reasonable and wanted fix. Keeping the limit count to 1 keeps us from getting ourselves into too much trouble with pathological cases, and we solve our common-case issue.

Comment 4

[Eric Faust [:efaust]]

Probably the easiest thing to do here is to take the last type flag and make it some idea of CANT_BE_UNCONFIGURED. The flag starts false, and allows a single define property operation to happen which can be undone by the subsequent one. The idea here is that there are lots of operations: delete, freeze, seal, that we want to actually set the flag.

The main downside of such a simplistic scheme is that if you add the getter and setter seperately, this won't work, which is a bit of a shame, bordering into "we must find something better".

Another, more complicated, but probably "better" idea, is to use the flag to mean "CANT UNCONFIGURE" and then re-evaluate from the shape what the state of the CONFIGURED flag should be a defineProperty time, not allowing it to unset if the CANT_BE_UNCONFIGURED flag is set. This allows us to also get one delete, if we want, for what that's worth. It also means that we can centralize the setting/unsetting to a single function. Operations like freezing could then bypass the mechanism, setting CANT_BE_UNCONFIGURED immediately.

Comment 5

[Till Schneidereit [:till]]

I don't know if that's feasible at all, but what about setting CANT_BE_UNCONFIGURED the first time it becomes relevant to JIT-compiled code? Before that, we're still in slow-land anyway and further slowdowns due to reconfiguration shouldn't be that bad.

Comment 6

[Eric Faust [:efaust]]

That shouldn't be hard to do. Just waiting for 920689 to land to free up some Typeset flags.

Comment 7

[Eric Faust [:efaust]]

Till, how many objects are we talking about here?

One of the pervailing limitations is that we can only really model this information with TI if all the objects have singleton type. Obviously, in some cases, this will not be feasible.

Can you try to give a better indication of the kinds of use cases? Large property counts on small numbers of global objects? Just pervasive use? What are we talking about here?

Comment 8

[Till Schneidereit [:till]]

efaust, do you have the required infos? It seemed that way from our quick IRC conversation, but ping me if not.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Comment 10

[Jan de Mooij [:jandem]]

No longer applies post-TI-removal.