If the conservative marker had just a little bit more information it could do a better job, ie, it could retain less storage through pointer mis-identification. Suppose objects were self-identifying with a "header tag" in addition to being identified by the pointer tag. (This is common in other systems because it allows a precise marker to identify objects in the heap by scanning the heap.) Suppose also that the marker knows the header tags and the pointer tags. If the marker finds that a pointer p stripped of its pointer tag pt points to an object o with a header tag ht, that pointer is valid only if pt is zero or if pt and ht are in correspondence. (Even if we continue to work towards ever more precise marking, a better conservative marker makes sense because we're unlikely to see a move to fully exact marking on all platforms, ever.)

This would get rid of approxiamately 3/4 of random false positives right? b/c 0 and the tag are valid two of the 8 possibilities get scanned. We'd have to make sure all tagged ScriptObject* were done consistently (assuming we even have non-Atom based pointers out there) but that shouldn't be too hard. I think partial exact marking of the most popular object types is better route because we should be able to go beyond 3/4 pretty easily.

(In reply to comment #1) > This would get rid of approxiamately 3/4 of random false positives right? b/c 0 > and the tag are valid two of the 8 possibilities get scanned. We'd have to > make sure all tagged ScriptObject* were done consistently (assuming we even > have non-Atom based pointers out there) but that shouldn't be too hard. > > I think partial exact marking of the most popular object types is better route > because we should be able to go beyond 3/4 pretty easily. The technique would get rid of some fraction of the objects that remain conservatively scanned, crucially some fraction of the objects that are reached from conservatively scanned C++ stack frames.

A similar idea is to mark objects with a flag that effectively says, "this object is only reachable through exact references", that is, conservative pointers to or into the object are ignored. It would be tricky to use well but for some types of objects - notably all that are invisible to client code, and only visible to the VM - it may work.

There's several places where various internal objects (lets take ScopeChain and VTable as an example) are tagged with an ad-hoc scheme that hides the pointer in a uintptr_t, with getters that assert the proper tag, and setters that do the write barrier. What would it take to get pt/ht correspondence with these schemes? Off the cuff, it would be important for a given object with a specific ht, to always have the same pt, when used in a field like this. A concrete VTable might be used in one field of one object with a tag of 1, and in another field of another object with a tag of 2. (I have no idea if this actually happens, just saying...). I hate this ad-hoc pointer tagging, btw. It hides pointers from dehydra, for one thing, and each constellation of tag, getters, and setters, must be hand-checked and rewritten for each unique field. Maybe out of scope for this bug, but I'm wondering if we could design a parameterized write barrier with all the necessary functionality. For example, for the two-tagged-pointer case: template <class TYPE1, class TYPE2> Require the classes in TYPE1 and TYPE2 to declare what their pt and ht values are: (i'm getting handwavy with templates but i think this is close) class VTable { static const int PTRTAG = 1; static const int HDRTAG = 1; }; class ScopeChain { static const int PTRTAG = 2; static const int HDRTAG = 2; }

The adhoc intptr fields are wreaking havoc with safegc as well. I'll have a go at this template idea...

(In reply to comment #4) > I hate this ad-hoc pointer tagging, btw. It hides pointers from dehydra, for > one thing, and each constellation of tag, getters, and setters, must be > hand-checked and rewritten for each unique field. Yep -- most of it is present just to save a few bytes here and there. It may be that in at least some of the cases, the savings isn't worth the hassle.

the thing i hate most about it is the type laundering. Dehydra and I would be happier with: union { SomeType *some; OtherType *other; }; and the masking & tag checking just in the accessor functions. (or, add intptr_t to the union). at least then the types that can occupy the field would be clear in the field declaration. anyway, i'm all ears to see if a template could handle this pattern; then its all packaged up nicely.

see https://bugzilla.mozilla.org/show_bug.cgi?id=608708

Partly exact tracing (bug 576307) handles the first part of this bug, and bug 608708 handles the second part.

bulk verifying resolved !fixed issues