Search jQuery

jQuery Forum

Developing jQuery Core

rkatic

.data( object ) and memory-leak

Implemented

Maybe later
Under review
In-progress
Implemented
Will not implement

in Developing jQuery Core • 13 years ago

For quite some time now I had intention to open this discussion because of increasing tendency of using data/event API on native objects.

Why this is a problem?
Well, the current $.data implementation is optimized for host objects only, and not for native objects too.
In fact, it uses a cache object to store all related data and an expando with numerical values to keep references.
The need of such solution is unquestionable and it fits well because elements are normally "eliminated" by using .remove() that also cleans respective data. Native objects, in other hand, are not "eliminated" with such call, and related data exists until the window is closed.

Of course, this problem also exists with the event API, that uses data API to store handlers...

Solution A
Probably the easiest fix would consist on storing data as expando property of native objects.

// ...
if ( elem.nodeType ) {
cache[ id ] = dataObject;
elem[ expando ] = id;
} else {
elem[ expando ] = dataObject;
}
// ...

Inheritance problem
Unfortunately that fix would not be sufficient once the object inheritance will become mainstream.

var objA = {};
var objB = Object.create( objA );
$.data( objA, "foo", "bar" );
$.data( objB, "foo" ) // => "bar" - ok, I suppose..
// ..but..
$.data( objB, "foo", "barB" );
$.data( objA, "foo" ); // => "barB" - oh noo..
$.data( objA ) === $.data( objB ) // => true - ...objA and objB have the same data object!

If you think that the returned value at line 5 would be 'undefined', then using hasOwnProperty on reading objectData of native objects will resolve the problem at lines 7-9. Otherwise, keep reading.

Solution B
To inherit values of parent objects, we have to store values in native objects itself!

// ...
if ( elem.nodeType ) {
dataObject[ name ] = value;
} else {
elem[ expando +"_" + name ] = value;
}
// ...

The only lack of this solution is that we can not return the data object of the native object, because it doesn't exists!

$.data( objA ); // => null? there is no data objects for native objects!

But I think it's not a big deal...

EDIT: Reconsidering the first solution...

Replies(10)

rkatic

Re: .data( object ) and memory-leak

13 years ago

Ok, I think that solution A with hasOwnProperty is the way to go (for now at least).

Here is the gist.

Suppose it will be useful for those who massively uses data/event API on native objects.

jeresig

Re: Re: .data( object ) and memory-leak

13 years ago

So I don't think that the hasOwnProperty issue is as large as you made it out to be - it may even be intentional that the user is trying to inherit the same bound data/events as the 'parent' object.

For the other issue (binding the data directly to the object) I filed a ticket and landed a patch:
http://dev.jquery.com/ticket/6189

rkatic

Re: .data( object ) and memory-leak

13 years ago

var parent = {};
var childA = Object.create( parent );
var childB = Object.create( parent );
$.data( parent, "foo", "parent value" );
// This may even be intentional
$.data( childA, "foo" ) // => "parent value"
$.data( childB, "foo" ) // => "parent value"
// This may NOT be intentional
$.data( childA, "foo", "childA value" );
$.data( parent, "foo" ) // => "childA value"
$.data( childB, "foo" ) // => "childA value"

I know that it is unusual to set data to a prototype, but in pure prototypical inheritance (Object.create) there is no distinction between prototypes and instances.

dbjdbj

jQuery + ES5 = ?

13 years ago

".... So I don't think that the hasOwnProperty issue is as large as you made it out to be.."

There is one issue here, it seems ? The issue of jQuery conformance to ES5 ... Correct me if I am wrong, but ES5 is based on certain concepts. Which are defining the behaviour of ES5 objects. And one might adopt the view that jQuery should follow ES5 concepts , not the opposite ?

For example one, perhaps the key, fact about ES5 is that prototypical inheritance is now the official inheritance. They key concept. Something that was talked about for decades but is now officially, built into the language and enforced through existence of Object.create() , and friends. Immediate consequence is that it is also built into the language that properties up the prototype chain are by default NOT visited when using iteration built into the language. For example Array.prototype iteration methods do visit only objects own properties.

All in all, concepts which jQuery is not always following, currently. Which, one might conclude, is indeed a "big deal". $.data() reveals this, also $.each() , $.isEmptyObject() etc ...

Most of this can be easily changed to confirm to ES5 logic. But. There is a question of legacy code that depends on jQuery not confirming always to ES5 logic. For that reason John is thinking of making (for example) jQuery.forEach() instead of changing jQuery.each() , etc. Recent JSON parsing issue is a prime example of change that was made to confirm to ES5. jQuery has changed to force legal JSON syntax. Which is a "good thing" but has provoked a lot of changes in a lot of legacy code around a planet.

This conceptual ES5 conformance change I think is big deal since it requires deep changes inside jQuery. Which is additionally complicated with legacy code and legacy browsers support.

But, all of this is certainly doable. It just requires a decision into which direction it will take jQuery.

Otherwise the confusion might arise, like in the posts above. if $.data() changes to "do" JavaScript objects, is it following ES5 concepts or not?

And, last but not the least: how is jQuery behaving in presence of ES5+"use strict" ? Doable, but not easily I guess.

All of this might be not immediate issue, but , I think, requires immediate and clear message from John Resig, to us on this forum, and ultimately to the wider jQuery community.

John, take us to ES5 ;)

--DBJ

rkatic

Re: .data( object ) and memory-leak

13 years ago

I am not so good with English, so let me explain the previous code with some diagrams.

To reproduce the problem, we are going to set a data to the parent object:

The data object doesn't exists before, so it is created to store the new value.

Now, we are going to change the same data for the object childA:

Data object doesn't exists for childA, so climbing the prototype chain, the parent's one is taken. So the parent's value is now overwritten!

Now getting "foo" from parent or childB (or any other parent's child) will return "childA value" instead of "parent value"!

To prevent this, we can use hasOwnProperty to retrieve only own data objects:

Now the childA value will not be propagated UP to the prototype chain.

Naturally this means that childs will not inherit parent's values any more.
In fact, avoiding hasOwnProperty on reading operations, would retrieve parent's values only if the object has no a data object.

So, if we don't wont to inherit data values from parents, then we have to use hasOwnProperty on reading and on writing, otherwise we have to adopt the Solution B.

dbjdbj

Re: Re: .data( object ) and memory-leak

13 years ago

Very good Robert. I certainly think diagrams are most helpful in this discussions.

Although this is not "legal UML" : JavaScript certainly requires object diagrams.

But for actual time bound view on instances and messages (aka method calls) object sequence diagrams are irreplaceable. It would be most useful to see them here.

Ugh, right now I simply do not have time to do them and post them here ;o(

--DBJ

rkatic

Re: .data( object ) and memory-leak

13 years ago

Don't think that this $.data issues are correlated with any strategic decisions (ES5).
In fact, prototypical inheritance is already a part of the language and ES5 Object.create is only a more handy way to use it.
I uses Object.create in my code for two reasons: 1) It is obvious what it dose (built-in or defined); 2) it emphasise that there is no strict distinction between prototypes and instances, specially with something like Object.create.

Also, here hasOwnProperty is even more important (Solution A) than in situations that you are exposing, because $.each and $.isEmptyObject are almost always used with plain objects that are used as hashes, while $.data will be used almost always with objects that are used as instances.

EDIT: Removed use of "plain-object" to be more clear..

dbjdbj

Re: Re: .data( object ) and memory-leak

13 years ago

"Don't think that this $.data issues are correlated with any strategic decisions (ES5)."

Since there is no (yet) strategy regarding jQuery move to ES5 full conformance, everything is (or might become) an issue when touching ES5 subjects.

" ...In fact, prototypical inheritance is already a part of the language and ES5 Object.create is only a more handy way to use it..."

That prototypical inheritance is "already part of the language" is I think well known to everybody here. It is only that after ES5 "classical inheritance" is not supported. The discusion is over. Prototypists have won. Game over for JavaScript "classes". Therefore jQuery does not have to support users still using it. jQuery is very benevolent library and it will try and support whatever, but not to its own detriment, I think.

"...there is no strict distinction between prototypes and instances"

Dont get emotional , but I think you are confused on this one. No worries, almost everybody is. There is no enough clear and simple (diagrams supported) definitive statements from member of ES5 comitee.

"...situations that you are exposing..."

I beg to differ. jQuery is "exposed" to ES5 same as every other library is. By the simple fact that ES5 is "signed in blood and cast in stone". Now everybody, sooner and latter, will have to conform to ES5.
Not an immediate process, though. Even browsers are still not there. But they should (or will) be by the end of 2010. Including IE9. I think jQuery should also follow that timeframe.

"..almost always used.."

library can not be developed under ambigious assumptions. one can not say : "this function will almost always work". behaviour has to be precisely defined, and it has to be documented unambigously.

"...plain objects that are used as hashes..."

"plain objects" ? Terminology must be consistent and formaly adopted. For that please use ES5 terms, definitions and concepts.

The point I was also making, admitedly not very clearly, is that jQuery (same as other known libs) has additional difficulty incured by the fact that it is, and want's to stay, backward compatible with older browsers.

Once more: I value your contribution, and indeed your diagrams. But I just have not enough time to dive inot details and support myself with "my" diagrams.

--DBJ

rkatic

Re: .data( object ) and memory-leak

13 years ago

"...there is no strict distinction between prototypes and instances"

Dont get emotional , but I think you are confused on this one. No worries, almost everybody is. There is no enough clear and simple (diagrams supported) definitive statements from member of ES5 comitee.

I don't get you. I was not talking about technical differences (ES3/5). I was talking how objects are used in an inheritance context. Nothing more.

"..almost always used.."

library can not be developed under ambigious assumptions. one can not say : "this function will almost always work". behaviour has to be precisely defined, and it has to be documented unambigously.

Not every legal usage is documented. $.data(object) is one of those. What I was saying is that some functions are designed with particular "type" of objects in mind.

"...plain objects that are used as hashes..."

"plain objects" ? Terminology must be consistent and formaly adopted. For that please use ES5 terms, definitions and concepts.

After introducing $.isPlainObject, I think the usage of "plain objects" is just fine and already adopted. And no, this is not an ES5 forum.

However, apart some misunderstandings and other minor aspects, I think we agrees on many things.

Although, it would be ideal to use hasOwnProperty in $.data, I will not push it any more, because not too important. My only intention was to expose possible implications for not using it.

dbjdbj

Re: Re: .data( object ) and memory-leak

13 years ago

"There's a whiff of the lynch mob or the lemming migration about any overlarge concentration of like-thinking individuals, no matter how virtuous their cause."
-- P. J. O'Rourke

Top Reply

Response title

Attachments

jQuery Forum

.data( object ) and memory-leak

Implemented

Replies(10)

Re: .data( object ) and memory-leak

Re: Re: .data( object ) and memory-leak

Re: .data( object ) and memory-leak

jQuery + ES5 = ?

Re: .data( object ) and memory-leak

Re: Re: .data( object ) and memory-leak

Re: .data( object ) and memory-leak

Re: Re: .data( object ) and memory-leak

Re: .data( object ) and memory-leak

Re: Re: .data( object ) and memory-leak

Statistics

Tags

Actions