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 Fri, 20 Jun 2008 10:10:34 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> Kristian Waagan wrote:
>> 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
>>>>>> 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?

The heuristic is not reliable because

  1) gc running concurrently may effect totalMemory() and freeMemory()

  2) threads running concurrently may effect totalMemory() and freeMemory()

  3) freeMemory() returns an approximation (according to its javadoc)

  4) the run-time optimizer may detect that the array is never used and
     optimize away the allocation

Not sure why we get unexpected values more frequently on 64-bit
machines, but it may be that freeMemory() returns a more accurate
approximation on 32-bit machines. It may also be because the heuristic
defaults to refSize==4 if sz<4, which increases the likelihood of
getting the expected value on 32-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?

It may impact performance, but if the code that uses these values is
correct, the impact should be positive. If the selected plans are worse
when we give more accurate input, I think the solution is to fix the
plan-selection algorithm, not faking the input to it.

Also, by checking the system properties, the plan selection is more
predictable, and it is easier to reproduce and fix problems if they

Knut Anders

View raw message