You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Matt Ryan <os...@mvryan.org> on 2016/09/16 23:08:32 UTC

Expected behavior of StringUtils.estimateMemoryUsage() ?

Hi,

I'm creating some unit tests for StringUtils.estimateMemoryUsage() in
oak-commons, and in doing so I noticed that it returns a value of 48 for an
empty string.  Is this expected?

From a naive point of view it would seem to me that a null string should
return 0, and likewise an empty string, but then again I don't know the
history behind the function as it is currently written.


-MR

Re: Expected behavior of StringUtils.estimateMemoryUsage() ?

Posted by Matt Ryan <os...@mvryan.org>.
I created OAK-4830 for this and submitted a patch to the ticket.  Thanks!

On Tue, Sep 20, 2016 at 1:15 AM, Marcel Reutegger <mr...@adobe.com>
wrote:

> On 19/09/16 16:08, Matt Ryan wrote:
>
>> What about for null though?  Currently this method will throw a null
>> pointer exception if a null string is passed in, which to me seems
>> suboptimal.
>>
>
> I agree, this can be improved. I guess so far we just didn't use
> it with null values. Can you please create an issue?
>
> Regards
>  Marcel
>

Re: Expected behavior of StringUtils.estimateMemoryUsage() ?

Posted by Marcel Reutegger <mr...@adobe.com>.
On 19/09/16 16:08, Matt Ryan wrote:
> What about for null though?  Currently this method will throw a null
> pointer exception if a null string is passed in, which to me seems
> suboptimal.

I agree, this can be improved. I guess so far we just didn't use
it with null values. Can you please create an issue?

Regards
  Marcel

Re: Expected behavior of StringUtils.estimateMemoryUsage() ?

Posted by Matt Ryan <os...@mvryan.org>.
Thanks Marcel, that's what I thought.

What about for null though?  Currently this method will throw a null
pointer exception if a null string is passed in, which to me seems
suboptimal.

On Mon, Sep 19, 2016 at 1:30 AM, Marcel Reutegger <mr...@adobe.com>
wrote:

> Hi Matt,
>
> 48 bytes is the shallow size of String object with a 64 Bit
> Oracle 7 JVM. In this version the String class also keeps
> offset and length fields, which means the estimate is rather
> conservative and slightly higher than what is e.g. needed
> for Oracle's Java 8. The latter only keeps a char[] and an
> int for the computed hash.
>
> As for the estimated value of an empty string. Even in this
> case the String will have the char[] and int for the hash.
> That is, the method will never return 0.
>
> Regards
>  Marcel
>
>
> On 17/09/16 01:08, Matt Ryan wrote:
>
>> Hi,
>>
>> I'm creating some unit tests for StringUtils.estimateMemoryUsage() in
>> oak-commons, and in doing so I noticed that it returns a value of 48 for
>> an
>> empty string.  Is this expected?
>>
>> From a naive point of view it would seem to me that a null string should
>> return 0, and likewise an empty string, but then again I don't know the
>> history behind the function as it is currently written.
>>
>>
>> -MR
>>
>>

Re: Expected behavior of StringUtils.estimateMemoryUsage() ?

Posted by Marcel Reutegger <mr...@adobe.com>.
Hi Matt,

48 bytes is the shallow size of String object with a 64 Bit
Oracle 7 JVM. In this version the String class also keeps
offset and length fields, which means the estimate is rather
conservative and slightly higher than what is e.g. needed
for Oracle's Java 8. The latter only keeps a char[] and an
int for the computed hash.

As for the estimated value of an empty string. Even in this
case the String will have the char[] and int for the hash.
That is, the method will never return 0.

Regards
  Marcel

On 17/09/16 01:08, Matt Ryan wrote:
> Hi,
>
> I'm creating some unit tests for StringUtils.estimateMemoryUsage() in
> oak-commons, and in doing so I noticed that it returns a value of 48 for an
> empty string.  Is this expected?
>
> From a naive point of view it would seem to me that a null string should
> return 0, and likewise an empty string, but then again I don't know the
> history behind the function as it is currently written.
>
>
> -MR
>