Proper handling of large mark stack insertion

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: gwagner, Assigned: gwagner)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
I noticed that for the FOTN the large markstack gets pretty full.
(Assignee)

Comment 1

6 years ago
Created attachment 528404 [details] [diff] [review]
patch
Assignee: general → anygregor
(Assignee)

Updated

6 years ago
Attachment #528404 - Flags: review?(wmccloskey)
Wait, this seems like a serious bug to me. Is there any guarantee that the assertion will succeed?

If push returns false, we should probably just do the normal thing and not use the large object path.

Thanks for finding this!
(Assignee)

Comment 3

6 years ago
Yeah I wanted to ask you why we don't check the return value there.
I will come up with another patch.
(Assignee)

Updated

6 years ago
Summary: Add success assertion for large mark stack insertion → Proper handling of large mark stack insertion
(Assignee)

Comment 4

6 years ago
Created attachment 528863 [details] [diff] [review]
patch
Attachment #528404 - Attachment is obsolete: true
Attachment #528404 - Flags: review?(wmccloskey)
(Assignee)

Updated

6 years ago
Attachment #528863 - Flags: review?(wmccloskey)
Comment on attachment 528863 [details] [diff] [review]
patch

Thanks.

Another way to do it is like this:
  if (...is large dense array... && gcmarker->largeStack.push(LargeMarkItem(obj)))
    /* do thing, push succeeded */;
  else
    clasp->trace(gcmarker, obj);

I'm not sure if this is better or worse, but it avoids code duplication.
Attachment #528863 - Flags: review?(wmccloskey) → review+
(Assignee)

Comment 6

6 years ago
Yeah I was thinking of the same code but I have never seen it in SM so I didn't want to start with it :)
(Assignee)

Comment 7

6 years ago
http://hg.mozilla.org/tracemonkey/rev/ebc5f8a4b233
Whiteboard: fixed-in-tracemonkey
cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/ebc5f8a4b233
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Blocks: 655562

Comment 9

6 years ago
Do we need this fix on Aurora or Beta?
(Assignee)

Comment 10

6 years ago
(In reply to comment #9)
> Do we need this fix on Aurora or Beta?

Depends if bug 616666 is in there.
Duplicate of this bug: 656761
(Assignee)

Comment 12

6 years ago
Bill is the explicit mark stack on Aurora?
(In reply to comment #12)
> Bill is the explicit mark stack on Aurora?

It seems like Aurora branched on 4/12 and bug 616666 went in on 4/26. So we're good.

It would be nice if there were a web page that listed the time and changeset id of each branch. Maybe there's an easy way to figure this out, but I ended up just searching through hg.mozilla.org, which is pretty annoying.
> It would be nice if there were a web page that listed the time and changeset
> id of each branch. Maybe there's an easy way to figure this out, but I ended
> up just searching through hg.mozilla.org, which is pretty annoying.

Just let cdleary-bot set the target milestone in bugzilla?
You need to log in before you can comment on or make changes to this bug.