Closed Bug 517749 Opened 15 years ago Closed 15 years ago

removal of weakRoots.newborn = null

Categories

(Core :: JavaScript Engine, enhancement)

x86
All
enhancement
Not set
normal

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)

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?
Attached patch v1 (obsolete) — Splinter Review
The patch removes weakRoots.newborn = null assignments. It also converts few related JS_PUSH/POP_TEMP_ROOTS into JSAutoTempValueRooter.
Attachment #401690 - Flags: review?(mrbkap)
Summary: removal of weekRoots.newborn = null → removal of weakRoots.newborn = null
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.  :-)
(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
Attached patch v2Splinter Review
synchronizing patch with the tip
Attachment #401690 - Attachment is obsolete: true
Attachment #402070 - Flags: review?(mrbkap)
Attachment #401690 - Flags: review?(mrbkap)
Attachment #402070 - Flags: review?(mrbkap) → review+
Comment on attachment 402070 [details] [diff] [review]
v2

I'm assuming that returning true and false from JSBool-returning functions is OK for now.
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
https://hg.mozilla.org/tracemonkey/rev/1980589f09ad
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/1980589f09ad
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: wanted1.9.2? → wanted1.9.2+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: