jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1663) REFERENCE properties produce duplicate strings in memory
Date Tue, 08 Jul 2008 16:52:31 GMT

    [ https://issues.apache.org/jira/browse/JCR-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611685#action_12611685

Thomas Mueller commented on JCR-1663:


This patch looks good, but there is a flaw. Not a bug, but it might lead to a bug later on
when somebody (for whatever reason) changes the code later on. See http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2707.pdf
 page 38ff. I don't want to spoil it in case you like to solve the puzzle yourself... By the
way, I can highly recommend the book "Java Puzzlers".

Something completely different: did you know that % (mod) is slower than & (bitwise and)?
Also the following wouldn't require Math.abs. You _need_ to use a power of 2 size then, but
you could document that as follows:

private final static int SIZE_POWER_OF_2 = 1 << 10;
private final Name[] names = new Name[SIZE_POWER_OF_2];
int position = name.hashCode() & (SIZE_POWER_OF_2 - 1);


> REFERENCE properties produce duplicate strings in memory
> --------------------------------------------------------
>                 Key: JCR-1663
>                 URL: https://issues.apache.org/jira/browse/JCR-1663
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-core, jackrabbit-spi-commons
>    Affects Versions: 1.4, core 1.4.5
>            Reporter: Roman Puchkovskiy
>         Attachments: JCR-1663.patch
> When reference property is loaded from PM, Serializer.deserialize(NodeReferences, InputStream)
is called, which calls PropertyId.valueOf(String), which in turn calls NameFactoryImpl.create(String)
which finally splits a full property name to namespace and local name. Namespace is internalized,
but local name is not (comments say that this is done to avoid perm space overfilling).
> So, in the end, a new String instance is created for local name. This leads to considerable
memory waste when repository has a lot of nodes with REFERENCE properties.
> It seems that local name part could be internalized here too because in the most repositories
it's not allowed to create properties with arbitrary names, so the danger of perm space exhaust
does not seem to be an argument.
> As for ways to resolve this, maybe a new NameFactory implementation could be created
which would be used for properties only (and, possibly, mainly in the PropertyId.valueOf(String))
which would extend an existing NameFactoryImpl overriding its create(String) method.
> What do you think about all this?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message