604798 - JM: Move JM ThreadData stuff to compartment

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

JM "globals", (e.g., the allocator for code memory) are currently in the ThreadData. But they should really be per-compartment instead, since compartment boundaries are the "real" thread boundary now.

Comment 1

[David Mandelin [:dmandelin]]

jorendorff, gal, can you give us some advice on this? I'm wondering where the jit data structures (both tracejit and methodjit) that are currently in JSThreadData should live.

- It seems to me that if jitcode only runs on the main thread, then the thread data is an OK place, basically a fake analogue to the runtime. But then we have the question, "Does jitcode in fact only run on the main thread?" Right now, jits are disabled for DOM workers, so I think this is supposed to be true, but I'm not sure if it's really true or how to know.

- If DOM workers are to run jits, then it seems like the wrong place. I'm told a given worker can run on different threads. So it would see different JSThreadData (I think), which seems very bad. It seems like the compartment is the right place to go in that case, because I think a DOM worker is associated with a single compartment. But compartment seems wrong for the main-thread stuff, because there are N compartments there, but N copies of the jitcode structures is totally unnecessary.

- And what about embedders? If they are currently using multiple threads, and they always call a given script from the same thread, then I think JSThreadData works. But I don't know what the restrictions really are.

Summarizing, it seems that the ideal situation is something like this:

- The program should be organized into "zones". A zone is a collection of compartments such that two threads never evaluate scripts in the same zone concurrently.

  - Because objects don't migrate across compartments, they don't migrate
    across zones.

  - "Zones" is not meant to be a good name, just a placeholder.

- jitcode data is mapped from the zone.

  - For JM, access to jitcode data is by script, so we can go from script to
    compartment to zone.

  - For TM, access to jitcode data is by global. For now, we can go from global
    to compartment to zone. I guess we are trying to remove that association.
    Without that, I guess we could use the zone for whatever global we are using
    right now, and we just might happen not to find data, in which case we'd
    just have to record traces again. This seems mostly OK, but doesn't seem
    that good for DOM workers, should we want to trace them someday.

Comment 2

[David Mandelin [:dmandelin]]

Attachment: WIP

It passes trace-tests at least, but that's easy. I think it's basically right, but I need to check a few things.

Also, I don't like names like "MethodJITData". If anyone has good ideas, let me know.

Comment 3

[David Mandelin [:dmandelin]]

Attachment: Patch

Comment 4

[David Mandelin [:dmandelin]]

http://hg.mozilla.org/tracemonkey/rev/394e0bd325b1

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

http://hg.mozilla.org/mozilla-central/rev/394e0bd325b1