[concurrency-interest] Question about re-ordering

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 17 23:33:13 EST 2012


And I just realized that maybe your question here is specifically about
System.nanoTime() as at the surface one may think that calling someMethod
is independent of the two nanoTime() calls and thus can be reordered.  If
we imagine that System.nanoTime() just read some non-volatile static
variable, then it certainly can change things around and inline the read of
the static variable, then inline someMethod, see that they're independent,
and shift things around.  In this case, however, nanoTime() is a VM call,
which I have a feeling serves as a compiler barrier in general (David can
probably confirm/deny that).  In addition, compiler has to inline the
method in order to see its guts before it knows that it can safely reorder
instructions.  If there's no inlining, I don't think it will move things
around as obviously it cannot "prove" that it's safe (e.g. that call may
have side-effects that it doesn't know about).

On Tue, Jan 17, 2012 at 11:19 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> Also, forgot to mention -- an optimizing compiler is an implementation
> detail.  You can have a JVM that does no optimizations -- code executes as
> you wrote it -- so I doubt (might be wrong though) that something like JLS
> would talk about compiler optimizations.
>
> Regards
>
>
> On Tue, Jan 17, 2012 at 11:17 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
>
>> Hi Yuval,
>>
>> As David mentioned, in general compiler is free to reorder instructions
>> such that within same thread you cannot observe the difference (code
>> behaves in the same manner as if it left it alone, i.e. sequential
>> execution as-written); compiler would have to "prove" that it's the case,
>> however, in order to do that.  In your example, changing that sequence
>> changes sequential behavior, so it cannot do that reordering.
>>
>> Vitaly
>>
>>
>> On Tue, Jan 17, 2012 at 10:42 PM, Yuval Shavit <yshavit at akiban.com>wrote:
>>
>>> This isn't concurrency related, but since we're talking about
>>> reordering, I've sometimes wondered what in the spec prevents the compiler
>>> from turning this:
>>>
>>>     long start = System.nanoTime();
>>>     someMethod();
>>>     long end = System.nanoTime();
>>>     long time = end - start;
>>>
>>> into the much less useful:
>>>
>>>     long start = System.nanoTime();
>>>     long end = System.nanoTime();
>>>     someMethod();
>>>     long time = end - start;
>>>
>>> or even:
>>>
>>>     long end = System.nanoTime();
>>>     long start = System.nanoTime();
>>>     someMethod();
>>>     long time = end - start;
>>>
>>> Obviously it's important that the actions not be reordered, but what
>>> prevents it? More generally, is there any definition in the JLS of what
>>> sorts of actions can and can't be reordered within a thread? I've looked a
>>> few times and have never found anything. Is there some sort of reordering
>>> fence at IO?
>>>
>>> On Tue, Jan 17, 2012 at 6:26 PM, David Holmes <davidcholmes at aapt.net.au>wrote:
>>>
>>>> From a theoretical perspective actions within a thread must appear to
>>>> occur
>>>> in program order, but any reordering is allowed that would not be
>>>> visible by
>>>> the thread. In practice without some aggressive inlining, and only if
>>>> intervening functions are trivially small, it is not likely that any
>>>> instructions from clear() would be reordered with any from put(). A
>>>> compiler
>>>> is not going to reorder two method calls unless it can ascertain it is
>>>> correct to do so - which in general it can not do.
>>>>
>>>> David Holmes
>>>>
>>>> > -----Original Message-----
>>>> > From: concurrency-interest-bounces at cs.oswego.edu
>>>> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Nader
>>>> > Aeinehchi
>>>> > Sent: Wednesday, 18 January 2012 9:12 AM
>>>> > To: concurrency-interest at cs.oswego.edu
>>>> > Subject: [concurrency-interest] Question about re-ordering
>>>> >
>>>> >
>>>> > Hi
>>>> >
>>>> > In the following, a listener is notified by some configurator.
>>>>  Question
>>>> > is whether a re-ordering may be enforced by compiler on the operations
>>>> > on "stateMap"?  Is it safe to assume that stateMap.clear() is always
>>>> run
>>>> > before stateMap.put within the same thread?
>>>> >
>>>> >      public void notify(ConfigurationEvent event) {
>>>> >          if (event.getType() ==
>>>> AbstractFileConfiguration.EVENT_RELOAD) {
>>>> >              logger.warn("log something");
>>>> >
>>>> >              stateMap.clear();
>>>> >
>>>> >              List<SubnodeConfiguration> configurations =
>>>> > xmlConfiguration.configurationsAt("*");
>>>> >              for (SubnodeConfiguration subnodeConfiguration :
>>>> > configurations) {
>>>> >
>>>> > stateMap.put(subnodeConfiguration.getString("@configurationId"), new
>>>> > State(subnodeConfiguration));
>>>> >              }
>>>> >          }
>>>> >      }
>>>> >
>>>> > Thanks
>>>> > _______________________________________________
>>>> > Concurrency-interest mailing list
>>>> > Concurrency-interest at cs.oswego.edu
>>>> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>> >
>>>>
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>
>>
>> --
>> Vitaly
>> 617-548-7007 (mobile)
>>
>
>
>
> --
> Vitaly
> 617-548-7007 (mobile)
>



-- 
Vitaly
617-548-7007 (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/2686abaf/attachment-0001.html>


More information about the Concurrency-interest mailing list