Re: Singletons?

Mark Space wrote:


     Somewhere where the garbage collector can find them if the
need should arise. In some JVMs, new objects live in "Eden."

     (More practically, how should "where" be answered in a way that
makes sense outside the context of a particular JVM? "Eden" or "the
broom closet" or "the back pocket" might all be correct answers, but
have you learned anything of value if someone says "New objects go
in the recirculating bi-phase yolk sac?" Even if he says "They go in
the heap," what has he told you? What can you conclude about the
nature and organization of this "heap" thing -- isn't "recirculating
bi-phase yolk sac" just as informative?)


     Entirely up to the JVM. You can experiment with the JVMs
available to you, doing something like

    MyClass[] array = new MyClass[SOME_BIG_NUMBER];
    RunTime rt = RunTime.getRunTime();
    for (int i = 0; i < array.length; ++i) {
        if (i % 1000 == 0)
            System.out.println("After " + i
                + " objects, " + rt.freeMemory()
                + " bytes remain.");
        array[i] = new MyClass();
    }

This should give you a set of "parallel" approximate line
segments interrupted by occasional GCs and with some "noise"
from other memory-eating activities. By eyeballing or even
least-squares fitting the segments, you can estimate the per-
object size. Of course, the results are only valid for the
JVM at hand.

     Also, I believe I've read that some JVMs optimize in ways
that can change the size of an object during its lifetime. The
thought is that the vast majority of objects are not synchronized,
so some JVMs (IIRC) defer allocating memory for a lock until it's
seen that the code actually synchronizes on the object. You might
be interested to modify the above test to make a second pass over
the array, just synchronizing on each object in turn to see if
the memory consumption changes.


     Trolling, are we? At the risk of feeding the troll, have
you taken a close look at a cell phone any time recently?

--
Eric Sosman
esosman@acm-dot-org.invalid