[
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:
-------------------------------------
Hi,
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);
Regards,
Thomas
> 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.
