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.
--
Kristian
(Not sure if it's relevant for this thread, but there was a brief
discussion about this code a while a go in DERBY-1902.)
