[concurrency-interest] Question about re-ordering

Joe Bowbeer joe.bowbeer at gmail.com
Wed Jan 18 00:03:33 EST 2012


The JLS does mention compiler (and microprocessor) optimizations:

http://java.sun.com/docs/books/jls/third_edition/html/memory.html

The JLS also says that the execution of data race free programs is
sequentially consistent, which rules out any observable reordering of
statements in the body of a method.

Joe

On Tue, Jan 17, 2012 at 8:19 PM, Vitaly Davidovich 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 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 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 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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/e3a68755/attachment.html>


More information about the Concurrency-interest mailing list