db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Advice in debugging plan selection
Date Thu, 19 Jun 2008 12:16:53 GMT
Kristian Waagan <Kristian.Waagan@Sun.COM> 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.

(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.)

-- 
Knut Anders

Mime
View raw message