896759 - Split out UNMARKED_SLOTS from Class::NON_NATIVE

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Steve Fink [:sfink] [:s:]]

If you are storing nonheap data or weak pointers in an object's slots, you need to use the Class::NON_NATIVE flag to prevent the slots from getting marked automatically. But Class::NON_NATIVE means other things too, eg you have to fill out an auxiliary operations table. It would be better if the slot marking control flag were separate.

I'm not sure what the best name would be.

 - UNMARKED_SLOTS
 - UNTRACED_SLOTS
 - MANUAL_SLOT_TRACING
 - MANUAL_SLOT_MARKING
 - MANUAL_MARK_SLOTS
 - MANUAL_TRACE_SLOTS

It looks like flag space is pretty tight, though. Maybe we could steal from the cached proto key stuff.

Comment 1

[Nicholas Nethercote [inactive]]

I started looking at this.  AFAICT the tricky part is that the value of NON_NATIVE ends up affecting Class::isNative(), Shape::isNative(), and Object::isNative().  The first two aren't that bad, but Object::isNative() is used all over the place, and unpicking the exact meaning of "isNative" in all those locations is difficult...

Comment 2

[Steve Fink [:sfink] [:s:]]

Does it matter? In my mind, isNative()'s meaning is a gooey gob of stuff, one piece of which is "the objects' slots are Values that can hold strong pointers to gc things." So I figured that you could audit all of the flag tests, and see which of them used that aspect of the isNative() meaning. I was naively thinking that it would be a small number of places that would depend on this particular part of the meaning -- specifically, the ones that decided whether to mark the slots or not. I could be totally wrong, and this aspect of the meaning is too tangled up with the other aspects.

For the record, my understanding of isNative() is based largely on guesswork and only a little on reading actual code. But I think of isNative() as meaning "native to the spidermonkey VM -- a 'normal' object, where we understand and control exactly how this object is going to accessed and updated, so we can make lots of assumptions about how it will behave." So, for example, a native Shape tells you everything you need to know about its layout. A NON_NATIVE object would be free to update multiple slots when you change one, change its layout, store raw data into the slots area, or in general break all kinds of invariants that most other objects can rely upon. As a result, it cannot use any of the fast paths unless its specific Class is checked for by some optimization that is aware that the NON_NATIVEness doesn't matter for that particular optimization.

FWIW, my understanding of JSFunction::isNative() is the direct *opposite* of JSObject::isNative(). JSFunction::isNative() is "native to the host environment" and therefore alien to spidermonkey's regular way of doing things. A JSFunction::isNative() object has a function pointer (of type JSNative) that can do arbitrarily unexpected things and so can't use the usual fast paths.

Assuming I am correct, one or the other or both of these really ought to be renamed.