Kristian Waagan wrote:
Knut Anders Hatlen wrote:
Kristian Waagan <[EMAIL PROTECTED]> writes:
Kathey Marsden wrote:
Kathey Marsden wrote:
Also I think I might try to gc() before the measurements and see if
that makes a difference, but it seems to me that would only make
the value larger.
putting runtime.gc() and runtime.runFinalization() before the calls
to totalMemory() and freeMemory() seem to stabilize it at 4.
Does that seem like a reasonable solution? The static block is only
called once so it shouldn't impact performance I think.
Can we use the system property "os.arch" to determine this?
+1
The calculation seems unreliable at best, so checking os.arch sounds
more robust to me. If we don't know the size of the references on that
architecture, or if we don't have permission to read the property, we
could fall back to gc() and freeMemory(). In Sun's JVMs you can also
check the property sun.arch.data.model, which is 32 when the JVM is
32-bit and 64 if it's 64-bit.
Just for clarity, note that "os.arch" is in the list of mandatory
properties, "sun.arch.data.model" is not.
This doesn't mean that we can't use the latter, only we can't expect
to find it in all JVMs.
One thing I noticed is that our heuristic seems to return 4 for refSize
even on the IBM 1.6 64 bit JVM (with the gc(). I didn't try it
without). Knut indicated that he had also seen the same issue with Sun
64bit JVM's ). I wonder two things.
1) Why does the heuristic not give the expected result on 64 bit machines?
2) If we change over to use os.arch and start returning 8 for 64 bit
platforms, do we run too significant a risk of changing query plans and
impacting performance on existing applications run on 64bit machines?
Kathey
