Hi Cameron,
Cameron McCormack <[EMAIL PROTECTED]> wrote on 02/20/2006 02:51:05 AM:
> [EMAIL PROTECTED]:
> > I'm worried that these represent a very significant
> > Memory leak. How are these managed as documents go
> > into/out of scope? (think someone twiddling the
> > xlink:href on an image/use element).
>
> Ok I have investigated this a bit more. Using WeakReferences in the
> childContexts set does avoid the problem of the resource documents not
> being GCed if they are subsequently unreferenced before the document
> ends.
Good.
> However, there is another problem that I have came across while poring
> over the output from 'hat'. For the case where a dynamic SVG 1.2
> document is used as a resource document, it won't be GCed because of
> some caching going on by Rhino.[...]
> The "reference chain from rootset excluding weak references" shows that
> the SVG12BridgeContext (and its document) are referenced from a static
> member of org.mozilla.javascript.JavaMembers, which seems to be
> caching various reflections of Java object methods (such as those in
> the document).
Hmm, this is a problem. We used to have this problem for all
Documents the solution was to call:
Context.setCachingEnabled(false); // clears the static cache
Context.setCachingEnabled(true);
When the 'root' document went out of scope.
It may be that we need to always run with Caching disabled.
Or else we will need to find a way to be 'notified' when the
image element reference is cleared (perhaps using the
batik.util.CleanerThread.WeakReferenceCleared class? Although
it's not entirely clear what we would WeakReference as it must
be something that _will_ go to GC when the reference changes
even if the rest doesn't - we could potentially create such
an item).
We might also check with the Rhino folks to see if they have
any suggestions on how to avoid this problem.
> The reference comes about because the JS 'parent'
> property of each of these functions is set to the window wrapper
> objects, o.a.b.script.rhino.svg12.GlobalWrapper, and that object has a
> reference to the Window object in the ScriptingEnvironment object.
Just so you know, the problem is actually wider than this in
general, IIRC you get references like this in a fairly wide number
of cases where you can't really avoid it (registering event listeners
etc). So you can't hope to really avoid the problem by making the
'parent' object some sort of weak reference.
> So I'm not sure what to do about this. Despite what to do for a
> technical solution, I don't know how GC of SVG 1.2 resource documents
> should be handled. Since they have their own script environments, which
> could be doing any manner of things in the background, and because of
> the text in "Externally referenced documents" in [1], I'm not sure that
> the document should be GCed until the primary document has gone out of
> scope. Regardless, it would be good to solve the problem with Rhino
> caching.
Well for my 2cents. I think any SVG document referenced from the image
element should have it's script run (it is true that the current 1.1 impls
don't do this, but I think this is generally acknowledged as a
shortfall/bug).
The SVG 1.2 spec makes this clearer.
As for when/if they can go to GC the question is how can what they are
doing in the background be visible to the user? I personally don't think
it's worth worrying about a child document 'manipulating' the parent
document - this is more likely to be an attack than 'correct' behavior.
If they want 'persistant' script then they should reference the JS from
the
parent document.
I think the child docs should become eligible for GC as soon as the
image reference is changed/removed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
