565825 - Eliminate shared properties

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

20:09:44 < gal> Waldo: ping
20:10:03 < Waldo> gal: pong
20:10:17 < gal> waldo, is there a way to get all properties of an object in ES5, including non-enumerable?
20:10:40 < Waldo> Object.getOwnPropertyNames
20:10:43 < gal> lovely
20:10:51 < gal> you didn't implement that yet did you?
20:11:10 < Waldo> you bitrotted me :-)
20:11:21 < gal> I make it up to you
20:11:21 < Waldo> but it wasn't done anyway
20:11:34 < gal> I just implemented it sorta accidentally, minus the ES5 veneer on top
20:11:51 < gal> similar to EnumerateOwnProperties
20:11:55 < gal> there is now GetOwnProperties
20:11:57 < Waldo> even not-own, own properties?
20:12:16 < Waldo> e.g. [].length
20:12:26 < gal> if thats what you want, its a 1-character fix
20:12:36 < Waldo> I doubt it
20:12:41 < gal> oh, you mean shared?
20:12:45 < Waldo> yes
20:12:52 < gal> $%^&
20:12:56 < gal> yeah, ok, so I _mostly_ fixed this
20:12:58 < Waldo> ^2
20:13:02 < gal> the hard part I will leave to you ;)
20:13:10 < Waldo> heh
20:13:13 < gal> (needed this for proxies)
20:13:27 < gal> that is really just ridiculous
20:13:39 < Waldo> preach it!
20:17:37 < gal> waldo, I have a very heretic idea
20:17:51 < gal> shared properties are there so we can keep an empty scope despite wanting a local property
20:17:59 < gal> however, brendan is about to delete scope
20:18:05 < gal> which eliminates the empty scope stuff
20:18:11 < gal> so shared properties are totally pointless
20:18:20 < gal> lets get rid of them!
20:19:24 < Waldo> blasphemous-and righteous

Comment 1

[Boris Zbarsky [:bzbarsky]]

By shared properties, are we talking JSPROP_SHARED?  Isn't the benefit of that (in addition to whatever scope stuff) that no slot is allocated for the property either?

Comment 2

[Andreas Gal :gal]

Yes, JSPROP_SHARED. And no, they do have a property, they just don't have a scope and a JSScopeProperty in the direct object (thats all in the prototype). Think length of a string. Its different for every string, so you need a slot in the direct object, but the property is described in the prototype.

Comment 3

[Brendan Eich [:brendan]]

Slotless, bitches!

Pay attention. You do not need a slot in the direct object. JSPROP_SHARED says to avoid this. Removing it costs you a slot in every object, which in addition to that direct cost, also entrains garbage. Read the code harder, cut back on the sophomoric stunt mis-readings.

/be

Comment 4

[Andreas Gal :gal]

Sorry for being slow here, but that doesn't make sense to me. The slot is needed in the object anyway. Are you telling me all String objects we have can store their various different length in String.prototype? With SHARED String stores its slot in fslots. Without SHARED, String would store its slot in the same place. RegExp also uses SHARED with slots in the direct object. I didn't look at XML, but who cares.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Its different for every string, so you need a slot in the direct object

No, you just need a getter that knows where to look for it in the JSString.  Similarly, for DOM shared props you just need a getter/setter that knows what C++ method to call.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Maybe we're having confusion here over the term "slot"?  JSPROP_SHARED means no need for an entry in fslots/dslots for the property value.  Obviously the getter will need to get something from somewhere, but it's pretty free to do this however it wants (for example, it could compute it every time from some other properties of the object).

Comment 7

[Andreas Gal :gal]

Sure, I am not saying we should eliminate slotless properties. If you don't need a slot you can look it up elsewhere. I am just saying it doesn't have to be shared, with all the painful effects on getOwnProperties(), aka try-to-enumerate-all-own-properties-including-non-enumerable-in-the-presence-of-shared-properties-that-are-not-own-but-sorta-are.

Comment 8

[Andreas Gal :gal]

The property of JSPROP_SHARED I am trying to get rid of is declaring it on the prototype object. See comment #7.

Comment 9

[Brendan Eich [:brendan]]

The slot is *not* needed for the object "anyway" -- read the code! JSPROP_SHARED means no slot is allocated, period.

getOwnPropertyNames (not getOwnProperties) can suck it up.

The problem with a value property is precisely twofold:
1. It costs a slot per object, prototype and instance object.
2. It retains the last-got value, which entrains garbage resulting in bloat.

/be

Comment 10

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  So that would effectively give us the JSC/Opera/V8 behavior in the DOM, fwiw.  It's a little wacky, because you can override _methods_ on DOM prototypes, but can't override property getters and setters, in those engines.  But maybe that's ok.

Comment 11

[Andreas Gal :gal]

Again, I am not asking for a slot. I did read the code, and I am trying my best to understanding. I am asking for a slotless property to be defined in the direct object. I am not asking for a slot if its not needed. No GC bloat.

Comment 12

[Brendan Eich [:brendan]]

Slotless means not only no direct object ("own") slot, but no direct object (times one million instances) property map, AKA scope. Just the prototype scope.

Re: comment 10 -- WebIDL is specifying this, AFAICT. It's not what WebKit did, olliej was lamenting the loss of efficiency because WebKit is planning to switch to follow the WebIDL ES binding spec. Until now, WebKit had a "last-ditch" get and set path that could reflect on singleton (truly global) C++ induced type info.

Slotless could be split from shared, so you can shadow a proto slotless prop with a direct one. This would restore more native object semantics.

/be

Comment 13

[Brendan Eich [:brendan]]

(In reply to comment #12)
> Slotless could be split from shared, so you can shadow a proto slotless prop
> with a direct one. This would restore more native object semantics.

Jason may have filed a bug on this. If not, it could be filed. Reopening and morphing this bug seems bad, though.

The original DOM in Netscape 2 used slotful proxy-like instances of prototypes for all DOM elements. The private data slot connected each instance to its peer C struct. There was no need for "own" properties and (if you didn't set a shadowing property on an instance) no direct slots. But the prototype object's slots entrained heaps of garbage.

Beyond the savings in space and entrainment hazard elimination, the native-ness of these DOM objects was crucial. IE took the "host object" route, proxying to COM, but losing lots of native goodness (e.g., !(window.alert instanceof Function) in the IE DOM level 0).

JSPROP_SHARED came later (end of 2000, IIRC). It killed two birds with one stone: no slot, and no shadowability. Again, separating these might be worth investigating.

When getters and setters were added, we kept the ability to have a slot, but user-defined getters and setters are JSPROP_SHARED. I'd like to make it so you can't have both a getter/setter and a slot. This would get rid of non-standard (ES5) complexity, reducing code size and pruning state space; it would allow us to compress property tree nodes a bit.

/be

Comment 14

[Igor Bukanov]

(In reply to comment #13)
> I'd like to make it so you
> can't have both a getter/setter and a slot.

Do you mean also for native getters/setters? If so it would mean making any property with a native/scrippted getter/setter JSPROP_SHARED or slotless. That would simplify a lot of slot handling cases.