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 A21099C30 for ; Wed, 14 Mar 2012 15:03:12 +0000 (UTC) Received: (qmail 53030 invoked by uid 500); 14 Mar 2012 15:03:11 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 52950 invoked by uid 500); 14 Mar 2012 15:03:11 -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 52911 invoked by uid 99); 14 Mar 2012 15:03:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Mar 2012 15:03:11 +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; Wed, 14 Mar 2012 15:03:07 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 713201FF4B for ; Wed, 14 Mar 2012 15:02:46 +0000 (UTC) Date: Wed, 14 Mar 2012 15:02:46 +0000 (UTC) From: "Uwe Schindler (Commented) (JIRA)" To: dev@lucene.apache.org Message-ID: <1117935631.13028.1331737366479.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <465341840.11785.1331706218099.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (LUCENE-3867) RamUsageEstimator.NUM_BYTES_ARRAY_HEADER is 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:comment-tabpanel&focusedCommentId=13229244#comment-13229244 ] Uwe Schindler commented on LUCENE-3867: --------------------------------------- On Hotspot Mailing list some people also seem to have an idea about jRockit and IBM J9: {quote} From: Krystal Mok [mailto:rednaxelafx@gmail.com] Sent: Wednesday, March 14, 2012 3:46 PM To: Uwe Schindler Cc: Dawid Weiss; hotspot compiler Subject: Re: How to detect if the VM is running with compact refs from within the VM (no agent)? Hi, Just in case you'd care, the same MXBean could be used to detect compressed references on JRockit, too. It's probably available starting from JRockit R28. Instead of "UseCompressedOops", use "CompressedRefs" as the VM option name on JRockit. Don't know how to extract this information for J9 without another whole bunch of hackeries...well, you could try this, on a "best-effort" basis for platform detection: IBM J9's VM version string contains the compressed reference information. Example: $ export JAVA_OPTS='-Xcompressedrefs' $ groovysh Groovy Shell (1.7.7, JVM: 1.7.0) Type 'help' or '\h' for help. ---------------------------------------------------------------------------------------------------------------------------- groovy:000> System.getProperty 'java.vm.info' ===> JRE 1.7.0 Linux amd64-64 Compressed References 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592_CMPRSS J9CL - 20110810_88604 groovy:000> quit So grepping for "Compressed References" in the "java.vm.info" system property gives you the clue. - Kris {quote} > RamUsageEstimator.NUM_BYTES_ARRAY_HEADER is 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 > > > 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