[
https://issues.apache.org/jira/browse/LUCENE-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910813#comment-13910813
]
Uwe Schindler edited comment on LUCENE-5463 at 2/24/14 9:10 PM:
----------------------------------------------------------------
There is an additional bug in the commit:
The static overload for String size is just wrong, see the recent failure:
{noformat}
REGRESSION: org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads
Error Message:
expected:<48> but was:<56>
Stack Trace:
java.lang.AssertionError: expected:<48> but was:<56>
at
__randomizedtesting.SeedInfo.seed([E123F914DF5BE037:BA7853CB2A89A039]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at
org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads(TestRamUsageEstimator.java:91)
{noformat}
The code uses an internal assumption on how a string is built internally. This
assumption may not be correct for all JVMs. There is nothing in the JDK spec
that specifies how a String should look like internally. Especially if it is a
substring of another string: in that case the array is larger than
string.length(). So the code is just wrong (in addition to this failure).
The static overload is just incorrect then, so please remove it or make it use
correct sizes, e.g. when the measured string is a substring of another one. Or
if the JDK uses another internal String representation. The latter can be
checked out *before* by inspecting string internals on the RUE startup.
was (Author: thetaphi):
There is an additional bug in the commit:
The static overload for String size is just wrong, see the recent failure:
{noformat}
REGRESSION: org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads
Error Message:
expected:<48> but was:<56>
Stack Trace:
java.lang.AssertionError: expected:<48> but was:<56>
at
__randomizedtesting.SeedInfo.seed([E123F914DF5BE037:BA7853CB2A89A039]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at
org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads(TestRamUsageEstimator.java:91)
{{noformat}
The code uses an internal assumption on how a string is built internally. This
assumption may not be correct for all JVMs. There is nothing in the JDK spec
that specifies how a String should look like internally. Especially if it is a
substring of another string: in that case the array is larger than
string.length(). So the code is just wrong (in addition to this failure).
The static overload is just incorrect then, so please remove it or make it use
correct sizes, e.g. when the measured string is a substring of another one. Or
if the JDK uses another internal String representation. The latter can be
checked out *before* by inspecting string internals on the RUE startup.
> Make RamUsageEstimator.(human)sizeOf(Object) a forbidden API
> ------------------------------------------------------------
>
> Key: LUCENE-5463
> URL: https://issues.apache.org/jira/browse/LUCENE-5463
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Fix For: 4.8
>
> Attachments: LUCENE-5463.patch, LUCENE-5463.patch
>
>
> We have had a few issues with {{RamUsageEstimator}} recently so I think we
> should consider making the {{sizeOf(Object)}} and {{humanSizeOf(Object)}}
> methods forbidden under src/java (however still allowed for tests as it is
> handy to check the size computations which are done "manually"). However,
> {{sizeOf(byte[])}}, {{shallowSizeOf(Class)}}, etc. remain useful so I think
> we should keep them allowed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
