664250 - Remove JSCLASS_FREEZE_{PROTO,CTOR}

Status: RESOLVED DUPLICATE of bug 924720

(Core :: JavaScript Engine, defect)

Description

[Brendan Eich [:brendan]]

See blocked bug. This should have been a one-off freeze call in jsiter.cpp. We should try to "GC" other JSCLASS_* flags too.

A further work item is to avoid freezing StopIteration just so we can share it among a compartment's globals, but that item requires some new API proposed for ES.next. Separate bug to be filed...

Andreas, can you take this one?

/be

Comment 1

[Andreas Gal :gal]

Attachment: patch

Comment 2

[Andreas Gal :gal]

StopIteration is not wrapped when it crosses a membrane. Instead we translate the origin compartment's StopIteration object into the current global's StopIteration object. This is necessary because we inspect the StopIteration object's identity in various places and a wrapped StopIteration object has its own identity and we don't want to unwrap all over the engine. If we freeze the proto and ctor (which is the object really used when throwing StopIteration), we avoid strange behavior such as this one:

compartment A:

StopIteration.x
throw StopIteration

compartment B:

catch (e) {
   alert(e.x); // x is not present, since this is a different global's StopIteration
}

I think we can live with this and just remove the freezing code.

Comment 3

[Jeff Walden [:Waldo]]

Compartment per global would address a bit of the last few comments' concerns!

Comment 4

[Chris Peterson [:cpeterson]]

efaust landed an equivalent patch for bug 924720:

https://hg.mozilla.org/mozilla-central/rev/32aeb054f757