One thing to add...
I was tracking down an issue that someone was having internally with
using the Disposer and thought that maybe the problem was that they
didn't understand how we use the DisposerTarget interface. Strange that
their query and your email were separated only by minutes. ;-)
It turns out that their problem was unrelated, but in doing my
investigation I noticed that our nicely written doc comments for the
Disposer* classes don't really describe how the DisposerTarget is used,
so I'll try to describe that here:
Basically, a naive user of Disposer might have a Java object which
points at some native data and they will want to register that object
with the Disposer along with some code to dispose the native data.
A problem typically arises in that such objects typically also hold
references to a lot of other data. Since that object was registered in
a queue to track its lifetime, that other data can be prevented from
being garbage collected while the Disposer queue is later processed.
The time might be small, but if the subordinate data is large and you
need it collected right away to satisfy other allocations, you can run
into OutOfMemory situations a lot more easily.
The workaround is to register a different object in the queues - one
that has the same lifetime as the original object which holds the native
resources, but which holds on to little (or nothing) else so its
footprint is small. The DisposerTarget interface allows the Disposer to
ask the object being registered if it has a "proxy" object to stand in
for it in the queues. We use that a lot since most of our classes with
native resources hold on to a lot of data and we don't want them hanging
around in a queue during the Disposer cycle.
You can look at the src/share/classes/sun/java2d/SurfaceData.java class
for an example of how DisposerTarget is used...
...jim
Dmitri Trembovetski wrote:
Hi Gili,
you can take a look at the source at
http://openjdk.java.net, see
j2se/src/share/classes/sun/java2d/Disposer*.java
j2se/src/share/native/sun/java2d/Disposer.c/h
It's relatively well documented..
But shortly, it uses ReferenceQueue and WeakReferences.
It puts a weak reference to the tracked object
into a reference queue and when the object is gone
the reference is retrieved from the queue,
it disposes the resources associated with the
object (those resources are kept in a special
DisposerRecord object).
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
Hi,
The following two BugParade issues discuss how Sun replaced class
finalizers using the Java2D Disposer mechanism:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6247526
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6299405
This peaked my curiosity, how does this mechanism work?
Thank you,
Gili
[Message sent by forum member 'cowwoc' (cowwoc)]
http://forums.java.net/jive/thread.jspa?messageID=239660
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff JAVA2D-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
