[
https://issues.apache.org/jira/browse/DERBY-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613257#action_12613257
]
Kristian Waagan commented on DERBY-3731:
----------------------------------------
Relying on Runtime.gc is not the best solution in my opinion and the call can
even be disabled on the command line (at least for the Sun JVMs), causing it to
have no effect. I've seen this done in appserver environments to reduce impact
of ill-behaved applications doing explicit GC.
The calculations are also sensitive to other kinds of activities in the JVM, so
I'd like to see further improvements to these calculations.
I don't know much about this code, but I see Knut Anders has already posted a
list of potential issues.
It seems feasible to code an algorithm using the following mechanisms to
determine the refSize (i.e. 32 or 64 bit system):
1) Use system property "sun.arch.data.model"
2) Use system property "os.arch" (requires some more logic/investigation)
3) Fall back to the existing logic.
If nobody else feels the itch, I can make a change proposal for the refSize
calculation, and if accepted, see how that affects our tests.
> Improve calculation of refSize in ClassSize.java
> -------------------------------------------------
>
> Key: DERBY-3731
> URL: https://issues.apache.org/jira/browse/DERBY-3731
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Reporter: Kathey Marsden
> Priority: Minor
> Attachments: DERBY-3731_diff.txt
>
>
> java/engine/org/apache/derby/iapi/services/cache/ClassSize.java has a static
> code block which calculates the size of a reference for the architecture.
> This code could be improved by adding garbage collection before measuring
> memory, to give a consistent reading. Also there have been suggestions
> that we use os.arch or sun.arch.data.model to make the measurement more
> reliable, especially on 64bit machines.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
