Make some nanojit classes initialize their members

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: jorendorff, Assigned: jorendorff)

Tracking

({fixed1.9.1})

Other Branch
fixed1.9.1
Points:
---
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
We go through the silliness of allocating our nanojit objects with an avmplus::GC, but the only reason for that is that LirBuffer's constructor (and maybe others) doesn't initialize its members.  All the GC does is zero them.

Low priority but I find this embarrassing.
Second this, IIRC Adobe wanted it to be optional so we'd have to #ifdef it.
(Assignee)

Comment 2

9 years ago
Created attachment 361564 [details] [diff] [review]
v1

The "#ifndef __MMgc__" here is because of comment 1.  I didn't bother in the case of LirBuffer or Fragmento, as I think they are long-lived and so the performance of the constructor doesn't matter.
Assignee: general → jorendorff
Status: NEW → ASSIGNED
Attachment #361564 - Flags: review?(gal)
Attachment #361564 - Flags: review?(edwsmith)

Updated

9 years ago
Attachment #361564 - Flags: review?(edwsmith) → review+

Comment 3

9 years ago
Comment on attachment 361564 [details] [diff] [review]
v1

you're right that it's both embarrasing and low priority.  in terms of code size there are plenty other places we can reduce before size of initializers really matters.  (cough) macros.  no #ifdef necessary.

Updated

9 years ago
Attachment #361564 - Flags: review?(gal) → review+
(Assignee)

Comment 4

9 years ago
Pushed to the Tracemonkey branch.

http://hg.mozilla.org/tracemonkey/rev/780189ed095c
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.