removing JS_SetObjectHook
Andreas Gal
I would like to remove JS_SetObjectHook. It requires a branch and some code in the hottest part of our object allocation path. I don't think anyone is currently using this API. Debuggers like firebug can easily observe explicit object creation through single-stepping and/or breakpoints. Observing implicit object creation is pretty strange to begin with, and might expose objects the VM doesn't expect to escape in the first place.
https://bugzilla.mozilla.org/show_bug.cgi?id=578159
If anyone is currently using this API, please let me know.
Andreas
John J Barton
We have a project to implement annew way to do debugging. The Java
prototype is complete and we are now working on a JS prototype. Key to
this new approach is to detect object creation so we can hook object
property modification.
We don't call JS_SetObjectHook directly as we are only using JS code. I
don't know how to detect object creation with single
stepping/breakpoints as you suggest, can you give more hints?
Separately Firebug support break-on-property change, and to correctly
implement it we also need to detect object creation on eg reload so we
can set the property change hook.
Thanks,
jjb
Andreas Gal
Ok, so to make sure I am understanding you correctly: you are not using JS_SetObjectHook currently, and you won't be using it in the future either (since you are using pure JS). Right?
As for detecting explicit object creation, basically if you set a breakpoint on all "new" expressions (or at the bytecode level JSOP_NEW), you should be able to see all objects that are created explicitly. You can watch properties on such objects using the watch mechanism.
This will not reveal objects created internally (iterator objects, DOM nodes, wrappers, etc).
Andreas
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
Wes Garland
> Ok, so to make sure I am understanding you correctly: you are not using
JS_SetObjectHook currently,
> and you won't be using it in the future either (since you are using pure
JS). Right?
IIUC, jbj uses "JS" from a firefox extension, which allows him to use the
jsdIDebuggerService, which is an xpcom reflection of JSD, specified in
js/jsd/idl -- this is not pure JS.
I think what jbj is saying is that he doesn't know if he is calling
JS_SetObjectHook() because he doesn't know how jsdIDebuggerService is
implemented (nor should he have to).
John, please call me out if I'm mistaken.
Andreas, JS_SetObjectHook() *is* called in JSD. It's referenced in
jsd_high.cpp and jsdebug.cpp. Oddly, my local JSD fork (which is a fork of
timeless' fork) doesn't use it in jsdebug.cpp.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Andreas Gal
thanks for the clarification. I was planning to remove the hook from JSD as well obviously. My concern about the current API is that it exposes objects the VM doesn't expect to be exposed (i.e. iterator objects, certain kinds of optimized closures, proxy handlers). We are making certain assumptions about such special objects, which might be violated by a debugger using this API, which will result in a crash best case. This is already an existing problem.
In addition to this I am trying to slim down the allocation path, which is badly needed for better object creation performance.
I guess my question is: is there any current use of the object hook that can't be achieved by observing explicit object allocations (for which the hook isn't required).
We won't apply the patch until this discussion is settled. There is no rush on this decision.
Andreas
Andreas Gal
Looking at the firebug source it seems firebug explicitly disables object tracing (which is implemented in JSD using JS_SetObjectHook).
jsd = DebuggerService.getService(jsdIDebuggerService);
jsd.flags |= DISABLE_OBJECT_TRACE;
John, is this correct? I am not very familiar with firebug.
johnjbarton
>
> Ok, so to make sure I am understanding you correctly: you are not using JS_SetObjectHook currently, and you won't be using it in the future either (since you are using pure JS). Right?
In firebug we set
jsd.flags |= DISABLE_OBJECT_TRACE;
mainly because of Lore from the Old Days said we should. I guess this
means Firebug as it currently operates would not miss JS_SetObjectHook.
In our research prototype we set
jsd.flags = 0;
and discover new properties:
objectValue.creatorURL
objectValue.creatorLine
objectValue.constructorURL
I guess that this means that JS_SetObjectHook is called as a consequence
of JS operations.
Essentially similar operations are needed to correctly implement break
on property.
On the theory that jsdv2 will still be coming there are other options.
For example the student (Salman Mirghasemi) suggested a debug call back
for property names rather like object.watch but not set on a particular
object. That way if I really want foo.bar, I can ask for all 'bar',
filter for 'foo' in the debugger and hope it's not too many.
>
> As for detecting explicit object creation, basically if you set a breakpoint on all "new" expressions (or at the bytecode level JSOP_NEW), you should be able to see all objects that are created explicitly.
But since jsd does not reveal the bytecode, we are not able to use this
approach. I guess we could decompile the source and grep for 'new'
tokens. Again jsdv2 could come to the rescue.
> You can watch properties on such objects using the watch mechanism.
Yes, we do this.
>
> This will not reveal objects created internally (iterator objects, DOM nodes, wrappers, etc).
Probably developers would think that is a feature.
jjb
johnjbarton
>
> Looking at the firebug source it seems firebug explicitly disables object tracing (which is implemented in JSD using JS_SetObjectHook).
>
> jsd = DebuggerService.getService(jsdIDebuggerService);
> jsd.flags |= DISABLE_OBJECT_TRACE;
> John, is this correct? I am not very familiar with firebug.
Yes, this is correct, though as I outline in the other post this is
really because we've got the basics in firebug now.
jjb
Andreas Gal
> On the theory that jsdv2 will still be coming there are other options. For example the student (Salman Mirghasemi) suggested a debug call back for property names rather like object.watch but not set on a particular object. That way if I really want foo.bar, I can ask for all 'bar', filter for 'foo' in the debugger and hope it's not too many.
This is definitely something we can do. Its similar to watchpoints in gdb. It would probably come at a substantial performance overhead when enabled (I am guessing 5-10x, same for gdb btw), but it would be free if not enabled. Want to file a bug on this? "Conditional watchpoints for property accesses". We have an intern who is working on debugging support for Jaegermonkey and this is relatively easy to wire up (we just trap all SETPROP/GETPROP operations). It would help if you describe in the bug the way you want to use this in the debugger so we can figure out what platform mechanisms we need at the jsd and engine level.
Andreas