[
https://issues.apache.org/jira/browse/HBASE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638804#comment-13638804
]
stack commented on HBASE-8384:
------------------------------
Patch looks good. Did you try locally passing -d32 (run on 32bit jvm) and it
still passed for you?
bq. On a tangentially related note, if we can obtain size programmatically (the
way we do it in test), and only need to do it once, I wonder if we should just
do it and remove all the manually modifiable constants stuff.
Yeah, we could do the above; would just be a bit of research and comparing our
values/validating our findings w/ the various attempts at sizeof in java.
> heap size computation for HStore is fishy
> -----------------------------------------
>
> Key: HBASE-8384
> URL: https://issues.apache.org/jira/browse/HBASE-8384
> Project: HBase
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Minor
> Attachments: HBASE-8384-v0.patch
>
>
> There's something off with heap size computation for HStore. If one adds a
> long to HStore, and size of long to the computation, TestHeapSize passes both
> locally (for me) and in jenkins. If one adds an int and size of int, it
> passes locally but fails in Jenkins. Perhaps the numbers are already off and
> some sort of packing is taking/not taking place differently.
> On a tangentially related note, if we can obtain size programmatically (the
> way we do it in test), and only need to do it once, I wonder if we should
> just do it and remove all the manually modifiable constants stuff.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
