Open Bug 641234 Opened 11 years ago Updated 11 years ago

Implement unique objectId for JavaScript object debugging

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

People

(Reporter: johnjbarton, Unassigned)

Details

(Whiteboard: [firebug-p2][querypoint])

Attachments

(1 file)

For the 'lastChange' querypoint debugging technique we need a unique identifier for every JavaScript object, an 'object identifier'. We want to compare this id at two different points in the execution sequence to test equality of an earlier reference to a current reference without storing the earlier reference and thus changing the program behavior.

To be clear, the id here is similar to a memory address. The value needs only be unique for one execution and one object creation. Two objects which are conceptually the same, eg window.foo now and window.foo in the last page reload, are not the same object and their object ids are not related.

The object id would also be useful for memory analysis.
Bug 317485 - Implement getObjectId for js
Seems very similar, never landed
Memory address doesn't work unless you keep objects alive, right?
We don't need the id for objects unless they are alive. But memory addresses by themselves won't work without some mechanism to know about GC. We need to know an object id is no longer valid; if GC can move objects we need the id to be updated.
Do you really need an id?  Or do you want something like ephemeron maps?
Well an id is easy to think about and to use, whereas:

B. Hayes,  "Ephemerons: A New Finalization Mechanism",  in Proc. OOPSLA, 1997, pp.176-183. 
Abstract:
Finalization occurs when a garbage collector informs an application that an object is "almost collectable." It is used to help an application maintain its invariants. To make finalization more useful, this paper defines "almost collectable" in terms of a new class of objects, called ephemerons. Ephemerons are similar to weak pairs, but an object in an ephemeron's key field may be classed as "almost collectable" even if it is reachable from the epehemeron's value fields.
Yes, but the upshot is that you can use the object itself as a key in a table and it'll automagically get cleaned up for you if the object is GCed.  So you can basically use the object itself as your "unique id".
So let me see if I get this:
   var efm = new EphemeronMap();
   {
       var foo = { bar: 1, baz: 2};  // the object I want to track

       efm.add(foo, new FabulousDebugInfo(foo));
   }
   // force gc
   var isMyFoo = efm.get(x);  // undefined since x can't ref foo *and* since 
                              // foo was GC anyway it's not even in the table.
As I understand, that's the idea, yes.
It is true that "we don't need id for objects unless they are alive" but the id uniqueness during the execution should be preserved. Therefore I think "memory address" won't work (at least alone).

I guess ephemeron maps are not what we need for this case. The reason is that we should keep collected debug info even for already dead objects. It is necessary for longer sequences of lastChange. 

We consider the fact that we usually need object Id for a very small proportion of objects in heap, therefore the mechanism should not add overhead to all objects.

I can think of these two solutions:

1) Like what we did in our prototype a hidden property is used for keeping the object id. The first time objectId() is called on the object, the property is added to the object. The only issue is getting the id value itself. In our prototype we simply get the new id by incrementing an integer. Here, I guess we must do it in a thread-safe manner. 

2) We can use memory address as the id but we need to be informed when the object is garbage collected. Then we know the id is obsolete, and we can recognize the next object with this id as a different object.
This approach needs a kind of hook for garbage collection, moreover we need to keep track of obsoleted ids.

Just to remind, we also need Id for scopes. Are scopes treated the same way?
I don't get it.  Most of comment 9 is talking about how you have to invalidate IDs when the object is GCed, but the second paragraph talks about how you need the ID to outlive the object... which is it?
We don't need to outlive the object. I just said we must keep the collected debug info about the object. So the object can be garbage collected but the collected debug info should be saved. Therefore we need object id (as a key) for this collected debug info.
Clear?
Ah, so you're storing the "id" in some other data structures too, so need to retrieve debug info for objects that are no longer live because something else is referencing the debug info via the id?
correct.
Whiteboard: [firebug-p2][querypoint]
Component: JavaScript Debugging/Profiling APIs → JavaScript Engine
You need to log in before you can comment on or make changes to this bug.