db-derby-dev mailing list archives

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

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.


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

View raw message