Issues:
1> none of these methods is ever called.
Note that Yonik's suggested patch for LUCENE-1607 contains the following
code:
+ public SimpleStringInterner(int sz) {
+cache = new String[BitUtil.nextHighestPowerOfTwo(sz)];
+ }
...so the int flavour of nextHighestPowerOfTwo() might be
You was. I just wanted to point out that in real apps you're not going
to see stale data longer than for milliseconds
Agreed, which is why this whole discussion is very theoretical anyway :)
On cache miss, I re-retrieve pool reference after a lock (HashMap is
no longer stale), re-read a string
se the stale/visibility
issue but it's clear you've already given that plenty of thought.
On Sun, Apr 19, 2009 at 23:42, Chris Miller
wrote:
As soon as all possible fields are in the pool, we're essentially
readonly.
The problem is, there's no guarantee we will ev
As soon as all possible fields are in the pool, we're essentially
readonly.
The problem is, there's no guarantee we will ever reach this point. For example
suppose you have a server app that spawns a new thread per request. Each
new thread might have to make all the .intern() calls again becau
How about benchmarking with eg a ConcurrentHashMap instead?
Scratch that, I forgot about the 1.3/1.4 dependency...
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h.
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 shou
This implementation suffers from thread visibility problems too - changes
to the array's values aren't guaranteed to be visible across threads. In
addition to that, there's also a problem with hash collisions invalidating
cache entries which could greatly degrade performance in several common us
The implementation of Interner doesn't look threadsafe to me. At the very
least shouldn't 'pool' be marked volatile, otherwise the result of 'pool
= newPool' is not guaranteed to be visible to other threads?
[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.j
ira.plugin.sy
