lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dawid Weiss (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3761) Generalize SearcherManager
Date Sat, 11 Feb 2012 16:11:59 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206159#comment-13206159
] 

Dawid Weiss commented on LUCENE-3761:
-------------------------------------

Bq. if you run this on a 64 bit server vm this program will deadlock while on a 32bit client
vm it won't.

Simon didn't mention that is the behavior under HotSpot, the result of running that code under
other VMs and hardware architectures is in general unpredictable.

The above behavior on HotSpot is in fact not a result of memory visibility problems (but it
could be!) but of how the code is seen by HotSpot jit optimizers. If the code is compiled
by c1 compiler (default on 32-bit jvms in -client mode) everything works (or tends to :) because
the loop: while (!ready) {} always accesses physical memory. Once the code is on-stack-replaced
with the c2 compiler (default second-tier optimizer for optimizer -server, it also explains
why you need a delay in T2), c2's optimizer sees while (!ready) {} as a constant (because
ready is not volatile and there are no happens-before with anything else) and promotes it
outside the loop. The machine code becomes something like:
{code}
if (!ready) {
  while(true) {/* spin */}
}
{code}

You can dump the assembly with debug versions of HotSpot and verify if I'm right. Another
cool way of seing such opotimizations in reality is to use gcj -O3 and compile to assembly
instead of an object file. 

(Sorry for being so verbose, this used to be part of a Java course I taught while in academia;
I'd seen wide eyes on folks that had been writing Java code for a good few years).
                
> Generalize SearcherManager
> --------------------------
>
>                 Key: LUCENE-3761
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3761
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/search
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>            Priority: Minor
>             Fix For: 3.6, 4.0
>
>         Attachments: LUCENE-3761.patch, LUCENE-3761.patch
>
>
> I'd like to generalize SearcherManager to a class which can manage instances of a certain
type of interfaces. The reason is that today SearcherManager knows how to handle IndexSearcher
instances. I have a SearcherManager which manages a pair of IndexSearcher and TaxonomyReader
pair.
> Recently, few concurrency bugs were fixed in SearcherManager, and I realized that I need
to apply them to my version as well. Which led me to think why can't we have an SM version
which is generic enough so that both my version and Lucene's can benefit from?
> The way I see SearcherManager, it can be divided into two parts: (1) the part that manages
the logic of acquire/release/maybeReopen (i.e., ensureOpen, protect from concurrency stuff
etc.), and (2) the part which handles IndexSearcher, or my SearcherTaxoPair. I'm thinking
that if we'll have an interface with incRef/decRef/tryIncRef/maybeRefresh, we can make SearcherManager
a generic class which handles this interface.
> I will post a patch with the initial idea, and we can continue from there.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message