Fast dereference detection in Java

Hi!

Is there any fast way of detecting when an object loses all its references in Java?

I'm currently using the WeakReference class to allow the garbage collector to decide for me when an object is no longer referenced. The issue is that its just too slow (I've written a unit test to demonstrate this - in the test it takes a System.gc() and a Thread.sleep(200) before the get() method on the weak reference returns null - far too slow for my application).

Thanks!
LVL 2
CheneyAsked:
Who is Participating?
 
gordon_vt02Commented:
You probably need to add your own layer between the GC and your classes to handle native references.  Create some class to manage those resources that tracks the number of classes that have referenced the resource, then make sure those classes close() it so your class can decrement the resource counter.  Have your thread check if your reference counter is 0 and dereference at that point, or just have your resource manager handle the cleanup when the reference counter goes to 0.

This approach will give you much more consistent results than relying on the GC, especially since the GC can vary dramatically between runtime implementations and based on the selected GC algorithm.
0
 
for_yanCommented:
why do you need this class WeakReference ?
Isn't it this decision a part of Java garbage collection operation?
0
 
for_yanCommented:
As far as I understand WeakReferences are used in order to maintain collections of objects that can grow too large
and also to avoid memory leask due to groups of mutually referencing objects which are not directly referenced by other objects and are unreachable can thus become permanently resident;
see here
http://en.wikipedia.org/wiki/Weak_reference
and here:

http://oreilly.com/catalog/javapt/chapter/ch04.html

They do not say that weak references speed up grabage collection.

which version of java are you using?

If you are concerned with garabge collection, and if you are not using Java 7, perhpas you want
to try Java 7 which has siginificantly changed garbage collection
which is getting good reviews:
http://stackoverflow.com/questions/2254041/java-g1-garbage-collection-in-production

0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
for_yanCommented:

and of course follow some advice on good practices related to garbage collcetion:
this rather old but still useful papers about it:

http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html

http://www.ibm.com/developerworks/java/library/j-jtp03216/index.html
0
 
CheneyAuthor Commented:
Thanks for your relies :)

I'm not so much worried about garbage collection itself. What I'm trying to do is almost implement my own garbage collection for objects which use native resources.

I'm using WeakReference so that I can find out when an object is no longer used so I can recycle its native resources. The issue is that its the garbage collector who decides when weakReference.get() stops returning my object and starts returning null.

I have a reaper thread which does the following continiously:

 
while(!Thread.interrupted()) {
    for(NativeInfo nInfo : info) {
       if(nInfo.getWeakReference.get() == null) {
             nInfo.recycleResources();
       }
    }

    Thread.yield();
}

Open in new window


Problem is even after my objects are dereferenced the loop above doesn't pick them up until after the next major garbage collection - which as my heap is mostly empty doesn't happen for a very long time. As a result I run out of native resources long before any of them get recycled and my app dies.
0
 
CheneyAuthor Commented:
Ideally I'd want recycleResources to be called the next time the reaper thread runs through the loop after the object is dereferenced by all the other threads which happen to have a strong reference to it.
0
 
CheneyAuthor Commented:
That makes sense.

I wanted to avoid intermediate classes and have the client having to clean up after themselves but it looks like it's the most reliable way forward. Maybe Java 7s try with resource will make it look less messy :)
0
 
CheneyAuthor Commented:
I ended up using reference counting as suggested and hand a handler class which implemented AutoClosable manage the count and hold the reference to my natives. That way the client can use Java 7s try with resource mechanism.

Its a shame I couldn't totally remove the responsibly of cleaning up from the client but this solution is good enough.

Thanks.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.