lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Miller <>
Subject Re: [jira] Commented: (LUCENE-1607) String.intern() faster alternative
Date Sun, 19 Apr 2009 20:34:06 GMT
Sorry I wasn't as clear as I could have been - I realise JEE servers use 
a threadpool for handling requests, I was thinking of many other applications 
in the real world I'm aware of that don't (be that good design or otherwise...). 
I'm not sure I follow you though when you say "it won't even do a write" 
on a cache miss, it copies the (potentially stale) HashMap in that situation 
does it not?

I still think there are some *theoretical* dangers (eg a thread replacing 
a well populated cache with a stale/empty copy). Just consider me pessimistic 
after having been burnt in the past by similar 'impossibilities' ;-) Overall 
though I'm in agreement that there aren't any practical issues with this 
code and in fact it'll give a good performance boost over String.intern() 
even in the worst case anyway! I was only trying to raise 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 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 because they never see anything in the cache.
> No sane server app is actually spawning a new thread per request, it
> takes one from pool. A spawned thread inherits visibility of its
> parent thread (at the moment of spawning). Even if a new thread still
> sees stale pool, it'll be updated on first cache miss. It won't even
> do a write. So, no "all the intern calls again", such scenario doesn't
> exist even in theory.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message