Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-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 8E2E4909B for ; Sat, 17 Mar 2012 14:54:01 +0000 (UTC) Received: (qmail 59132 invoked by uid 500); 17 Mar 2012 14:54:00 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 59032 invoked by uid 500); 17 Mar 2012 14:54:00 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 59025 invoked by uid 99); 17 Mar 2012 14:54:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Mar 2012 14:54:00 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Mar 2012 14:53:58 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 7F2AB2493B for ; Sat, 17 Mar 2012 14:53:38 +0000 (UTC) Date: Sat, 17 Mar 2012 14:53:38 +0000 (UTC) From: "Uwe Schindler (Updated) (JIRA)" To: dev@lucene.apache.org Message-ID: <1283929836.28193.1331996018522.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <465341840.11785.1331706218099.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (LUCENE-3867) RamUsageEstimator.NUM_BYTES_ARRAY_HEADER and other constants are incorrect MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/LUCENE-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3867: ---------------------------------- Attachment: LUCENE-3867.patch I separated the shallow Object inspection to a static method, which is more cheap (no RamUsageEstimator instance is needed). The static method now only takes a Class parameter and returns the size (an instance is not even needed). I also added a diagnostic boolean, so you can query RamUsageEstimator, if the used JVM is supported (supports Hotspot diagnostics, sum.misc.Unsafe). If that is not the case, our testcase will print a warning so users cam report back (if they run the tests). I think this is ready to commit. > RamUsageEstimator.NUM_BYTES_ARRAY_HEADER and other constants are incorrect > -------------------------------------------------------------------------- > > Key: LUCENE-3867 > URL: https://issues.apache.org/jira/browse/LUCENE-3867 > Project: Lucene - Java > Issue Type: Bug > Components: core/index > Reporter: Shai Erera > Assignee: Shai Erera > Priority: Trivial > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3867-compressedOops.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch, LUCENE-3867.patch > > > RamUsageEstimator.NUM_BYTES_ARRAY_HEADER is computed like that: NUM_BYTES_OBJECT_HEADER + NUM_BYTES_INT + NUM_BYTES_OBJECT_REF. The NUM_BYTES_OBJECT_REF part should not be included, at least not according to this page: http://www.javamex.com/tutorials/memory/array_memory_usage.shtml > {quote} > A single-dimension array is a single object. As expected, the array has the usual object header. However, this object head is 12 bytes to accommodate a four-byte array length. Then comes the actual array data which, as you might expect, consists of the number of elements multiplied by the number of bytes required for one element, depending on its type. The memory usage for one element is 4 bytes for an object reference ... > {quote} > While on it, I wrote a sizeOf(String) impl, and I wonder how do people feel about including such helper methods in RUE, as static, stateless, methods? It's not perfect, there's some room for improvement I'm sure, here it is: > {code} > /** > * Computes the approximate size of a String object. Note that if this object > * is also referenced by another object, you should add > * {@link RamUsageEstimator#NUM_BYTES_OBJECT_REF} to the result of this > * method. > */ > public static int sizeOf(String str) { > return 2 * str.length() + 6 // chars + additional safeness for arrays alignment > + 3 * RamUsageEstimator.NUM_BYTES_INT // String maintains 3 integers > + RamUsageEstimator.NUM_BYTES_ARRAY_HEADER // char[] array > + RamUsageEstimator.NUM_BYTES_OBJECT_HEADER; // String object > } > {code} > If people are not against it, I'd like to also add sizeOf(int[] / byte[] / long[] / double[] ... and String[]). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org