Closed
Bug 517749
Opened 15 years ago
Closed 15 years ago
removal of weakRoots.newborn = null
Categories
(Core :: JavaScript Engine, enhancement)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
People
(Reporter: igor, Assigned: igor)
References
Details
(Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file, 1 obsolete file)
30.97 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
Currently in a few places the code clears the newborn object on failures like in
cx->weakRoots.newborn[GCX_OBJECT] = NULL;
The idea behind this code is to prevent the GC to see partially initialized GC things like objects without the private data or without particular property.
Since the invention the local roots that are populated in NewGCThing such zeroing of newborn is not enough and the code is updated to properly deal in finalizers the missing values. Thus such clearing of newborn just adds to code bloat and should be removed.
Flags: wanted1.9.2?
Assignee | ||
Comment 1•15 years ago
|
||
The patch removes weakRoots.newborn = null assignments. It also converts few related JS_PUSH/POP_TEMP_ROOTS into JSAutoTempValueRooter.
Attachment #401690 -
Flags: review?(mrbkap)
Assignee | ||
Updated•15 years ago
|
Summary: removal of weekRoots.newborn = null → removal of weakRoots.newborn = null
Comment 2•15 years ago
|
||
I'm all in favor of removing these mostly-unexplained lines, but going so far as to request wanted? on it seems a bit much to me. :-)
Assignee | ||
Comment 3•15 years ago
|
||
(In reply to comment #2)
> but going so far as to request wanted? on it seems a bit much to me. :-)
This simplifies patching for bug 517199.
Blocks: 517199
Assignee | ||
Comment 4•15 years ago
|
||
synchronizing patch with the tip
Attachment #401690 -
Attachment is obsolete: true
Attachment #402070 -
Flags: review?(mrbkap)
Attachment #401690 -
Flags: review?(mrbkap)
Updated•15 years ago
|
Attachment #402070 -
Flags: review?(mrbkap) → review+
Comment 5•15 years ago
|
||
Comment on attachment 402070 [details] [diff] [review]
v2
I'm assuming that returning true and false from JSBool-returning functions is OK for now.
Comment 6•15 years ago
|
||
Returning true and false from JSBool return-typed functions is good for now and always. The JSBool taint is there cuz of either (a) API compat; (b) ABI issues in nanojit.
Still, we can use true and false instead of JS_TRUE and JS_FALSE, so we should. The ugly part we can't avoid is unwinding from ABI or API downcall such that the compiler sees a JSBool -> bool return value conversion, which requires !! or equivalent.
/be
Assignee | ||
Comment 7•15 years ago
|
||
Whiteboard: fixed-in-tracemonkey
Comment 8•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Flags: wanted1.9.2? → wanted1.9.2+
Comment 9•15 years ago
|
||
status1.9.2:
--- → beta1-fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•