Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2B30C112FA for ; Sun, 8 Jun 2014 21:55:07 +0000 (UTC) Received: (qmail 83849 invoked by uid 500); 8 Jun 2014 21:55:03 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 83746 invoked by uid 500); 8 Jun 2014 21:55:03 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 83689 invoked by uid 99); 8 Jun 2014 21:55:03 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Jun 2014 21:55:03 +0000 Date: Sun, 8 Jun 2014 21:55:03 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: dev@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (HBASE-1590) Extend TestHeapSize and ClassSize to do "deep" sizing of Objects MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-1590. ----------------------------------- Resolution: Won't Fix Stale issue. Reopen if still relevant (if there's new activity) > Extend TestHeapSize and ClassSize to do "deep" sizing of Objects > ---------------------------------------------------------------- > > Key: HBASE-1590 > URL: https://issues.apache.org/jira/browse/HBASE-1590 > Project: HBase > Issue Type: Improvement > Affects Versions: 0.20.0 > Reporter: Jonathan Gray > Assignee: stack > Priority: Minor > > As discussed in HBASE-1554 there is a bit of a disconnect between how ClassSize calculates the heap size and how we need to calculate heap size in our implementations. > For example, the LRU block cache can be sized via ClassSize, but it is a shallow sizing. There is a backing ConcurrentHashMap that is the largest memory consumer. However, ClassSize only counts that as a single reference. But in our heapSize() reporting, we want to include *everything* within that Object. > This issue is to resolve that dissonance. We may need to create an additional ClassSize.estimateDeep(), we may need to rethink our HeapSize interface, or maybe just leave it as is. The two primary goals of all this testing is to 1) ensure that if something is changed and the sizing is not updated, our tests fail, and 2) ensure our sizing is as accurate as possible. -- This message was sent by Atlassian JIRA (v6.2#6252)