any idea why we don't go to the toplevel scope in the NativeJavaObject constructor for setting the parent? #2275
Replies: 1 comment
|
I'm not sure why we have that particular difference in behaviour, put parent scope has been an absolute pain over the years for precisely this reason, and even holding on the top level scope can be a problem. Most objects don't need to hold this information, but functions generally do so that they can resolve references correctly, and built in functions also need it to find the correct built in for their realm. I've got two big test branches—one separating scopes and objects, and another moving every built in over to the new function and class descriptors, and once those two have landed we stand a much better change of removing
|
Uh oh!
There was an error while loading. Please reload this page.
see:
https://github.com/mozilla/rhino/blob/master/rhino/src/main/java/org/mozilla/javascript/NativeJavaObject.java#L50
for example newObject in ScriptRuntime:
https://github.com/mozilla/rhino/blob/master/rhino/src/main/java/org/mozilla/javascript/ScriptRuntime.java#L1329
does do that.
i was investigating a memory leak dump of a large heap dump, and we have some scopes that get destroyed/cleaned up
but inside that scope we can have created NativeJavaObject wrappers around java objects and the scope is then that specific scope
As far as i can see that has no meaning, when would that parent scope really by used? Especially why would we need the parent scope of the scope where that object is made? that wouldn't really have any meaning right?
If i would make new object via ScriptRuntime at that same level then we do set just the parent top level scope, so we always have a reference to the full engine/scope.
All reactions