[
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: [email protected]
For additional commands, e-mail: [email protected]
