As far as I can see, both these implementations only suffer from threadsafety
problems in that they don't guarantee visibility across threads, ie it's
possible for threads to see stale data. I don't see any prospect of corruption
or race conditions due to out-of-order execution. So the code should work
fine if you can live with the consequences of stale data - in this case,
the (remote) possibility of large performance differences between VMs. Personally
I tend to avoid such fragile and hard to maintain code unless there's a very
good reason for it.
How about benchmarking with eg a ConcurrentHashMap instead?
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.j
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=127
00600#action_12700600 ]
Mark Miller commented on LUCENE-1607:
-------------------------------------
bq. Earwin, I took a quick look at your implementation just now, but
it doesn't look thread-safe.
That was my first impression too, but I couldnt pin down the issue.
The access will either be against the old pool, or it will be against
the new pool, and the instance switch should be atomic? I figured it
was a clever trick of some kind (though I did wonder about the cost of
making the new hashmap every add). The HashMaps are read only right
(once they can be accessed by multiple threads)? And they are popped
in with an atomic variable assignment?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
