[jobim]

I'm using Cocoa Java and noticing some strange behavior.

Take Java Sketch, one of Apple's Java Cocoa examples. It is doing something my simple NSDocument Cocoa Java app is doing.

If I create a new document and close it, memory for some reason is kept around, ie the resident memory size for the process will not decrease. Open 50 new documents in Java Sketch and immediately close them to see the obscene memory bloat. According to the VM, objects are not kept around, via checks with Runtime.totalMemory() and Runtime.freeMemory(). So I'm assuming on the Objective-C side objects are, for some reason, being kept in memory.

Is there some special Foundation or AppKit code I need to call, seeing as Java has no explict memory free model being a VM?

[Ghoser777]

This is part of the reason why I moved on from Cocoa-Java to Coca-ObjC. There were large memory leaks with NSImage objects I was using and made my apps have real issues. But, I have heard that Panther has fixed some of these issues, so maybe all will be well soon.

If you finalize an object in Java, doesn't that tell the garbage collector to take out the trash?

Matt Fahrenbacher

[Arkham_c]

Originally posted by Ghoser777:
If you finalize an object in Java, doesn't that tell the garbage collector to take out the trash?

Nope. In java you cannot trigger garbage collection. All you can do is make an object available for collection, and "suggest" that java do collection.

[absmiths]

Originally posted by jobim:
I'm using Cocoa Java and noticing some strange behavior.

Take Java Sketch, one of Apple's Java Cocoa examples. It is doing something my simple NSDocument Cocoa Java app is doing.

If I create a new document and close it, memory for some reason is kept around, ie the resident memory size for the process will not decrease. Open 50 new documents in Java Sketch and immediately close them to see the obscene memory bloat. According to the VM, objects are not kept around, via checks with Runtime.totalMemory() and Runtime.freeMemory(). So I'm assuming on the Objective-C side objects are, for some reason, being kept in memory.

Is there some special Foundation or AppKit code I need to call, seeing as Java has no explict memory free model being a VM?

You also have to keep in mind that Java does not neccesarily reduce the size of the heap just because it has collected garbage. I have a server process here that is pure Java and the memory usage just climbs and climbs until it hits the max heap allocation then it jumps down to like 4MB and does it all over again. Maybe if you try to set the maximum (and initial) heap size to 8MB then that will cap it off (assuming that it isn't actually a leak, and that 8MB is enough to run Cocoa-Java.)

Oh, and there is no way to finalize an object in Java - objects have finalizers that get called by the VM at collection time (potentially).

[Kristoff]

Then there's the other possibility...are there any circular references that would keep the object from being gc'd?

[Michel Fortin]

Originally posted by Kristoff:
Then there's the other possibility...are there any circular references that would keep the object from being gc'd?

I think you should check your facts: circular references cause problem to retain counted mechanism like the one found in Obj-C Cocoa, but not to garbage collectors like the one in Java.

[jobim]

Originally posted by absmiths:
You also have to keep in mind that Java does not neccesarily reduce the size of the heap just because it has collected garbage. I have a server process here that is pure Java and the memory usage just climbs and climbs until it hits the max heap allocation then it jumps down to like 4MB and does it all over again. Maybe if you try to set the maximum (and initial) heap size to 8MB then that will cap it off (assuming that it isn't actually a leak, and that 8MB is enough to run Cocoa-Java.)

That I am fully aware of. Java often grows its heap size keeping around free memory in its heap, which makes sense, so it won't have to grow the heap every time memory is allocated. A good performance strategy.

However, Runtime has totalMemory() and freeMemory() calls which report the amount of used and free memory in the Java heap. And those measurements are always vastly lower than the overall process heap. So trying to restrict the Java VM heap won't help.

I undertand that Cocoa Java objects are simply Java wrappers for memory allocated by ObjectiveC in the app heap. Therefore, I can think of two cases where something is going wrong. One, Cocoa Java is keeping references around to the Cocoa Java objects, preventing them from being garbage collected, and hence preventing memory on the ObjectiveC side from being reclaimed, since I assume when the Cocoa Java object is reclaimed by the VM then so are the ObjectiveC objects. Two, Cocoa Java objects are garbage collected and still memory is not reclaimed on the ObjectiveC side due to some issue in Cocoa itself and perhaps the Java bridge.

Oh, and there is no way to finalize an object in Java - objects have finalizers that get called by the VM at collection time (potentially).

Yup, know that as well. However I find it odd that the Java VM would not run object finalization for, say, over 10 minutes after an object could be garbage collected. Becuase that's how long, and longer, memory is hanging around after I let go of the Cocoa Java objects. If this is how Cocoa Java releases its ObjectiveC memory, during finalize() on Cocoa Java objects.

However, I've never seen such delayed behavior of running finalization in any Java VM. Which makes me think something else is messed up.

As for my code having stray references to Cocoa Java objects (the usual Java "memory leak"), I don't have those. The Cocoa Java objects should be garbage collected. Unless Cocoa Java decides never to let go of my NSDocument objects.

[Kristoff]

Originally posted by Michel Fortin:
I think you should check your facts: circular references cause problem to retain counted mechanism like the one found in Obj-C Cocoa, but not to garbage collectors like the one in Java.

In Java, as long as there is a live reference to an object it will never be gc'd. Here is an example:

Assume an array called "storage" is managing a stack:

Code:
public Object pop(){
   return storage[index--];
}

if the caller of pop() abandons the popped object, it will not be eligable for gc until after the array element containing a reference to it is overwritten.

The mechanics of this example are exactly how most Java apps leak. There is some reference to an object that the author forgot about. I guess I was using the term "circular reference" to convey the concept of "unrecognized live reference". But, the concept is the same.