Garbage Collector

[Lance]

I am looking for a way to make my huge JavaOP2 plugin (and JavaOP2 overall, without modifying source) more efficient. I do not know exactly how the Garbage Collector works and when to invoke it. Can someone shed some light on this for me? Thanks.

[iago]

The garbage collector deletes objects that have no references to them. It should invoke itself on a regular basis, you probably don't need to invoke it.

To make your object get garbage collected, just delete any reference to it. As in, set the object to null, make sure it isn't in any lists, etc.

[Lance]

Ah, thats how I usually unset my variables.

Thanks!

[Chavo]

Out of curiosity, what criteria are you using to decide JavaOp needs to be more efficient?  I ask because you wouldn't be the first person to mistake flood protection for program slowness.

[Warrior]

The point of a GC is to take the stress of resource management largely off of the user.
Objects are released when a) You exit their scope, b) All references are removed or c) (not sure if this is possible in Java) explicitly invoke the GC.

[Chavo]

This article provides an excellent read if you are interested in how the java GC works and optimizing it:

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

However, it's an old article and I don't know how much of it pertains to more recent java verisons.

[Camel]

The point of a GC is to take the stress of resource management largely off of the user.
Objects are released when a) You exit their scope, b) All references are removed or c) (not sure if this is possible in Java) explicitly invoke the GC.

Not exactly. Firstly, A is just a special case of B. Secondly, C doesn't allow you to destroy a strongly referenced object. Lastly, that list is incomplete: there are four levels of reference strength:
* Phantom
* Weak
* Soft
* Strong

If there were only strong references, your B would be the only reason an object could become a candidate for GC. A strong reference is a direct reference; given:

Code Select Expand

Object o = new Object();
o is a strong reference to the new object, and that object can therefore not be a candidate for GC until o's scope closes, or possibly longer if the object becomes referenced by anything else.

Then you have 3 classes that built off of Refrence. Think of the reference class as such:

Code Select Expand

public abstract class Reference<T> {
    T ref;

    public Reference<T>(T ref) {
        this.ref = ref;
    }

    public T get() {
        return ref;
    }
}

The phantom reference never stores a copy of the object:

Code Select Expand

public class PhantomReference<T> extends Reference<T> {
    public PhantomReference<T>(T ref) {
        super(null);
    }
}

Then you have soft/weak references, which behave out of the ordinary with regards to the GC. These two types of references are only guaranteed to reference an object for as long as that object is strongly reachable. In the case of a weak reference, the object will be destroyed upon the first GC cycle. In the case of a soft reference, the GC will try to keep it around until it runs out of memory.

[Lance]

Out of curiosity, what criteria are you using to decide JavaOp needs to be more efficient?  I ask because you wouldn't be the first person to mistake flood protection for program slowness.

I want to lower the amount of memory JavaOP2 uses since it is temporarily on a low-memory windows system.

[Chavo]

Turn off the GUI Plugin then :)

[Lance]

Turn off the GUI Plugin then :)

For some reason, JavaOP2 is using more memory without the GUI plugin :(

[Camel]

You are probably using the Server GC profile. Add -client to the java command line.

[Lance]

I have more memory available now, so never mind. Thanks for all the help  :)