The default bug view has changed. See this FAQ.

Move the marking declarations out of jsgcmark.h and into a header with minimal dependencies

RESOLVED FIXED in mozilla15

Status

()

Core
JavaScript Engine
--
minor
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Waldo, Assigned: Waldo)

Tracking

Trunk
mozilla15
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Created attachment 620078 [details] [diff] [review]
Patch

As part of the new object/property/elements representation, I'm introducing a class that encapsulates the current Shape* stored in ObjectImpl.  (The idea is that we won't be conflating the ideas of a single property and an object's list of properties in the same representation.)  That class will contain a HeapPtr, which means I need to have the write barrier methods defined before the properties class is defined.  That means I need the corresponding marking methods declared by that point.  That means I need jsgcmarker.h.

I thought that depended on jscompartment.h, but it turns out it doesn't, actually -- that include can be removed at no cost.  I didn't realize this at the time, tho, so I wrote the patch.  I think it's a better state than previously -- moves stuff out of js/src into more precise directories, minimizes dependencies a bit, and generally makes things cleaner.  So how about this?

I tested this by removing all the contents of jsalloc.cpp and putting a single #include "gc/Markers.h" in it, then making sure that file compiled.
Attachment #620078 - Flags: review?(wmccloskey)
Created attachment 620124 [details] [diff] [review]
v2: Move jsgcmark into gc/, forward-declare some dependencies, and clamp down on over-inclusion
Attachment #620078 - Attachment is obsolete: true
Attachment #620078 - Flags: review?(wmccloskey)
Attachment #620124 - Flags: review?(wmccloskey)
Blocks: 751003
Attachment #620124 - Flags: review?(wmccloskey) → review+
Sorry, backed out on inbound because of build failure:
https://hg.mozilla.org/integration/mozilla-inbound/rev/26738df8a4e0
No worries, relanded and green after enough time that it's passed the original failure (it built all the way for me locally, too):

https://hg.mozilla.org/integration/mozilla-inbound/rev/bd3e28b8adfb

The problem was jsatom.h needed to see the HeapPtrAtom typedef (you can't predeclare types that are typedefs, unfortunately) that I moved to vm/String.h -- a non-installed header.  The simple fix was to use HeapPtr<JSAtom> rather than HeapPtrAtom, permitting the non-kosher #include to be removed.
Target Milestone: --- → mozilla15
(In reply to Jeff Walden [:Waldo] (busy, try to prefer other reviewers if possible) from comment #3)
> The problem was 

http://30.media.tumblr.com/tumblr_m11ykqEl0P1rrf1eeo1_500.jpg

:-)

https://hg.mozilla.org/mozilla-central/rev/bd3e28b8adfb
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.