Created attachment 620078 [details] [diff] [review]
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.
Created attachment 620124 [details] [diff] [review]
v2: Move jsgcmark into gc/, forward-declare some dependencies, and clamp down on over-inclusion
Sorry, backed out on inbound because of build failure:
No worries, relanded and green after enough time that it's passed the original failure (it built all the way for me locally, too):
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.
(In reply to Jeff Walden [:Waldo] (busy, try to prefer other reviewers if possible) from comment #3)
> The problem was