Yes, I actually attempted this same exact solution last night, but ran into a problem.
You are making the call to the debugger from within the ScriptableObject class right? And you are probably adding a similar debugger callback in the put(String,Scriptable) & delete methods also right? In any case, adding this update to the get, put, and delete methods of ScriptableObject should cover all the bases if we have the same understanding. But now the problem: -------------------- The way NativeArray is implemented, it overrides the get(int,Scriptable) method, and when a new element is added to an array it never calls the super.get(int,Scriptable) (not to mention the fact that it doesn't override get(String,Scripable), so behavior is different depending on which method you call, but presumably that is because get(String,Scriptable) isn't meant to get an array item, not pretty, but ok), so in the case of NativeArray our watch point callback is never made for array items (killer in my case since I want to watch *all* variable addition/changes/deletes). In any case, for this solution to work the subclass NativeArray would also have to know to make a debugger call (an in-elegant proposal). After thinking it through more it seems that the best solution is to use your approach to the debugger and re-write NativeArray so that it stores it's array items in the same data structure that super.put(int/String,Scriptable) uses, where super is ultimately the ScriptableObject base class. Then the NativeArray should maintain an array that keeps the array-elements in order (for use by JS) but only has a reference back to the objects stored in the super class data structure (this way the super class does the work of storing the elements), currently NativeArray stores array elements in its own data structure, and uses the super classes data structure for non array elements. As a technical note. NativeArray currently maintains array elements in a data structure local to the NativeArray class called "dense". ScriptableObject maintains a data structure of type Slot (I haven't looked into the details of the Slot class, but it appears to work similarly to a HashTable, and dense naturally appears to work similarly to an Array). If there is agreement that this is a good solution then I'm going to take on making the change to NativeArray and post the result in a new bug/enhancement request. David p.s. Have you posted your watchpoint solution in a bug/enhancement report already? If not I don't mind doing so if/when I post the change to NativeArray. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] a.org] On Behalf Of Johan Compagner Sent: Wednesday, November 12, 2008 8:28 PM To: [email protected] Subject: Re: Acknowledging when a new attribute is added to the scope We (eclipse dltk project) already have something for this patched in our js code: public Object get(String name, Scriptable start) { Context currentContext = Context.getCurrentContext(); if (currentContext != null) { Debugger debugger = currentContext.getDebugger(); if (debugger instanceof IDeguggerWithWatchPoints) { IDeguggerWithWatchPoints wp = (IDeguggerWithWatchPoints) debugger; wp.access(name, this); } } This is for access and modification (what you want) in the IdScriptable class I would hope that something like this would also make it in a release of rhino so that the debugger can have watchpoint support johan On Wed, Nov 12, 2008 at 3:56 PM, David Parks <[EMAIL PROTECTED]> wrote: > I have a question that I think I know the answer to, but before I commit > myself I want to validate that I am correct. > > The question: (the important part) > ============== > I have set up an implementation of an embedded debugger. I want to know if > I > can be notified any time a new attribute is added to my instance scope > (specifically, that's the scope that the script is running under, and any > child ScriptableObject(s) under it). > > > Why I need this: (extra detail) > ================= > I need to calculate the relative memory a script consumes (I don't need > absolute memory used, just a number I can compute relative to what other > scripts are running so that I can keep untrusted scripts from > over-allocating memory). > > > My current approach: (fyi) > ==================== > Is to recursively iterate over all ScriptableObject(s) from the instance > scope down using Scriptable.getIds() after every X lines of code execute. > It's pretty easy to computer a numeric value for each possible attribute > (null, Undefined, Number, String, Object+it's recursive attributes). > However > I run into a problem with multiple references (e.g. var y = new > Array("Green", "Blue"); var z = y[0]; both reference the same string > object). So if I use my approach I count the string "Green" twice which > isn't a fair representation of the actual memory utilization. > > My best solution to this, if I can't just get notified of a new attribute > creation, is to add a flag to ScriptableObject, then my recursive algorithm > above can flip it on each memCount operation to ensure it doesn't double > count objects with multiple references. However this requires me to change > the Rhino base classes which is inelegant. Not to mention the fact that a > full scan each X steps is inefficient. Thus my search for a better > solution. > > > Thanks! > David > > p.s. Norris: thanks for the previous response, I just didn't understand the > delete operator well enough, it now makes sense how to deal with the case. > > > > > _______________________________________________ > dev-tech-js-engine-rhino mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino > _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
