[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700696#action_12700696
]
Earwin Burrfoot commented on LUCENE-1607:
-----------------------------------------
Okay, you're probably right. It's not that hashmap can be corrupted on
subsequent write, it's that reader threads can possibly see not-yet-built
hashmap.
And volatile works, while simple sync doesn't, because volatile also orders
reads.
Hm. Hm. Hm.
Than, as you suggested, all we need is our own hash implementation that remains
usable even being partially updated. I skipped through your patch and something
looks suspicious to me. Like lack of collision resolve and that line:
int slot = h & (cache.length-1);
It'll break on non-power-of-two sizes.
> String.intern() faster alternative
> ----------------------------------
>
> Key: LUCENE-1607
> URL: https://issues.apache.org/jira/browse/LUCENE-1607
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Earwin Burrfoot
> Fix For: 2.9
>
> Attachments: intern.patch, LUCENE-1607.patch
>
>
> By using our own interned string pool on top of default, String.intern() can
> be greatly optimized.
> On my setup (java 6) this alternative runs ~15.8x faster for already interned
> strings, and ~2.2x faster for 'new String(interned)'
> For java 5 and 4 speedup is lower, but still considerable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
