JSCodeGenerator::upvarMap should be a js::Vector

RESOLVED FIXED in mozilla8

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: cdleary, Assigned: cdleary)

Tracking

unspecified
mozilla8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed-in-tracemonkey])

Attachments

(1 attachment)

Created attachment 544371 [details] [diff] [review]
upvarMap as vector.

Spotted this when I was working on another bug.
Attachment #544371 - Flags: review?(nnethercote)
Comment on attachment 544371 [details] [diff] [review]
upvarMap as vector.

Review of attachment 544371 [details] [diff] [review]:
-----------------------------------------------------------------

This seems fine, but the point is unclear.  I guess it's good to replace an ad-hoc array type with js::Vector?  But there's still several other JSUpvarArrays around;  getting rid of all of them would be a bigger win.

::: js/src/jsemit.cpp
@@ +2341,5 @@
> +            size_t lexdepCount = cg->roLexdeps->count();
> +
> +            JS_ASSERT_IF(!upvarMap.empty(), lexdepCount == upvarMap.length());
> +            if (upvarMap.empty())
> +                upvarMap.appendN(UpvarCookie(), lexdepCount);

Probably better to use infallibleAppendN(), it makes the precondition clearer.
Attachment #544371 - Flags: review?(nnethercote) → review+
(In reply to comment #1)
> This seems fine, but the point is unclear.  I guess it's good to replace an
> ad-hoc array type with js::Vector?  But there's still several other
> JSUpvarArrays around;  getting rid of all of them would be a bigger win.

The other ones are uses of the type embedded in JSScript, and we hate increasing the size of JSScript for memory footprint reasons.

Second comment is good -- it's actually fallible and I forgot to check! It's just a lazy vector capacity initialization like in the original.
http://hg.mozilla.org/tracemonkey/rev/1013f4be025f
Whiteboard: fixed-in-tracemonkey
Depends on: 670772
Whiteboard: fixed-in-tracemonkey → [fixed-in-tracemonkey] [inbound]
Backed out of m-i as part of a mass backout.
Whiteboard: [fixed-in-tracemonkey] [inbound] → [fixed-in-tracemonkey]
http://hg.mozilla.org/mozilla-central/rev/2bdcc80c8324
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in before you can comment on or make changes to this bug.