do self references cause memory leaks in Java?

[dhek bhun kho]

(e-mail address removed) (Bent C Dalager), Thu, 17 Jul 2003 07:15:14 +0000:

I'm not familiar with JVMPI so I'll just assume they know what they're
talking about <g>

<a href="http://java.sun.com/j2se/1.4.1/docs/guide/jvmpi/jvmpi.html">
It's the java layer of the debugging/profiling interface.</a> I would hope
that such a layer would be reliable to do profiling with. But then again
it's still experimental. I have no clue on the current development status
of the memory profiling code.

Nothing that I can think of.


Does it do this in some mystical magical way or has it just fired up
its own non-daemon thread to keep it all ticking merrily on? If it's
magical, that might affect how things are collected (or not) I
suppose.

Magical? You mean like casting a contingency spell to dimension door
every where with mirror images and stoneskin?

at it, it will still collect in its own good time. I tend to use
OptimizeIt to track down memory leaks and find my efforts constantly
frustrated by the fact that even when I have correctly unregistered
all my listeners, diposed all my windows, etc., it will still take up
to several minutes for the GC to catch on - even after hitting the
"collect" button in the profiler.

Makes profiling hard. Some people ask how they can obfuscate code, I
think the easiest way is to use a lot of indirection and patterns tied
together with a lot of native libraries. It's called Java.

frustrated by the fact that even when I have correctly unregistered
all my listeners, diposed all my windows, etc., it will still take up
to several minutes for the GC to catch on - even after hitting the
"collect" button in the profiler.

Well don't waste too much time on this. It's a very unreal test case, and
not worth the effort as if there is a leak and it's only 240 bytes in a
whole application, then it should be of no problem (as long as the leak is
just an one time happening).

What's even more unreal is that you would write a class where an instance
references itself. Does an object not always have a reference to itself?

Greets
Bhun.

 

[Bent C Dalager]

(e-mail address removed) (Bent C Dalager), Thu, 17 Jul 2003 07:15:14 +0000:

<a href="http://java.sun.com/j2se/1.4.1/docs/guide/jvmpi/jvmpi.html">
It's the java layer of the debugging/profiling interface.</a> I would hope
that such a layer would be reliable to do profiling with. But then again
it's still experimental. I have no clue on the current development status
of the memory profiling code.

I would _guess_ that there's still some leeway for the garbage
collector implementation to do whatever it bloody well pleases, but I
could be wrong of course.

Magical? You mean like casting a contingency spell to dimension door
every where with mirror images and stoneskin?

I can certainly see how that might confuse the garbage collector <g>

Well, unless it's Dilbert's garbage collector I suppose. He'd feel
right at home.

Makes profiling hard. Some people ask how they can obfuscate code, I
think the easiest way is to use a lot of indirection and patterns tied
together with a lot of native libraries. It's called Java.

There's a _reason_ there is a refactoring called "remove an

What's even more unreal is that you would write a class where an instance
references itself. Does an object not always have a reference to itself?

I don't think it would be too uncommon. At the very least, you could
get it in an object that holds references to other utility objects and
you have decided to implement these as part of the same class. That
is, you might have an API that goes something like

abstract class Foo
{
private FooPartner myPartner;
public void setPartner(FooPartner p) { myPartner = p; }
...
}

interface FooPartner
{
boolean beFriendly();
}

and then decide to make yourself a new Foo that does it all itself

class RealFoo extends Foo implements FooPartner
{
public RealFoo()
{
setPartner(this);
}
public boolean beFriendly()
{
System.out.println("Hi there pal");
return true;
}
}

Cheers
Bent D

 

[Robert Olofsson]

dhek bhun kho ([email protected]) wrote:
: (e-mail address removed) (Bent C Dalager), Thu, 17 Jul 2003 07:17:03 +0000:

: > Are you aware of any decent free ones?
: None. Are you aware of any decent free ones?

I use my own, it is free (GPL). It is called jmp and can be found at:
http://www.khelekore.org/jmp/

It does what I need and was developed because commercial versions
are _very_ expensive (for free projects at least) and comercial versions
did not give me what I wanted.

I tested both cases:
1) reference= new SelfReferent(this);
2) reference= new SelfReferent(reference);

It is said that example 2 does not create objects in the /evil/ way that
we want, but for what I can understand it does create 999 /evil/ objects
and 1 un-evil object.

/robo

 

[Robert Olofsson]

Bent C Dalager ([email protected]) wrote:
: If I understand you correctly, then the initial version of example 2
: creates 1000 non-evil objects because the local variable used is
: always null when the class constructor is entered. It is not a static
: member, it is an instance member, and it will be initialized to null
: just before the ctor gets started.

Doh!
Ok, now I feel stupid maybee I should try to read the code before
evaluating it. Guess I saw what was intended rather than what it was.

Anyway both the broken and the fixed version produced the same type
of results so this did not matter as Ive already stated.

/robo

 

[Michiel Konstapel]

I ran this through JProfiler (anybody want to fund me so I can buy a

license? I'm still doing backpayments on my 20' plasma tv).

20 feet? That's one damn big TV ;-)
Michiel

 

[Tukla Ratte]

On Thu, 17 Jul 2003 04:51:47 GMT, dhek bhun kho

I ran this through JProfiler (anybody want to fund me so I can buy a
license? I'm still doing backpayments on my 20' plasma tv).

Oh, yeah. You have my pity.

No, wait. That's envy. >

< snip >

 

[Tukla Ratte]

20 feet? That's one damn big TV ;-)
Michiel

o/ Frank's two-thousand-inch TV.
Everybody come and see...
You won't believe it! /o

 

[Jon Skeet]

Thomas G. Marshall

Fair enough. But Phillip's statement is precisely how I'd state what you
stated. I believe that saying "required to free all available memory"
/means/ "required to free as much as its gc knows how to".
Right.

However in your example, are you sure a GC's would be conformant to spec if
they were to allow only 65536 objects and never try to reuse references of
dead objects? That is, 65536 new objects, regardless of how many are freed?
Gads.

I believe that would be a conformant JVM. Not a useful one, but
conformant.

 

[Jon Skeet]

From my dodgy memory of the spec, I believe that the spec defines when
memory can be freed, and when it can not. In other words conformant
JVM's will have the same definition of whether a object can be freed
or not.

Hmm. From chapter 3:

<quote>
To implement the Java virtual machine correctly, you need only be able
to read the class file format and correctly perform the operations
specified therein. Implementation details that are not part of the Java
virtual machine's specification would unnecessarily constrain the
creativity of implementors. For example, the memory layout of run-time
data areas, the garbage-collection algorithm used, and any internal
optimization of the Java virtual machine instructions (for example,
translating them into machine code) are left to the discretion of the
implementor.
</quote>

On the other hand, from section 2.6:

<quote>
A class instance is explicitly created by a class instance creation
expression, or by invoking the newInstance method of class Class. An
array is explicitly created by an array creation expression. An object
is created in the heap and is garbage-collected after there are no more
references to it. Objects cannot be reclaimed or freed by explicit
language directives.

A JVM, for instance, which used strict reference counting would not be
conformant, because it could be made to run out of memory with
circular references. Hence it would run out before it had freed all
available memory, although it may well have freed as much as it's GC
knows how to.

This still leaves a lot of scope for different mechanisms for GC.

I believe a lot of VMs *were* conservative in their garbage collection
early on though. Maybe none of them conformed to the spec - chances are
they didn't in other ways anyway...