[concurrency-interest] _interrupted field visibility bug in OpenJDK 7+

Kearney, Joe Joe.Kearney at gsacapital.com
Thu Nov 8 05:23:44 EST 2012


Correction - 7u9 32-bit does exhibit this behaviour when you explicitly specify -server. This is all on Windows.

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Kearney, Joe
Sent: 08 November 2012 10:07
To: 'Dr Heinz M. Kabutz'; Vitaly Davidovich
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] _interrupted field visibility bug in OpenJDK 7+

Heinz,

I tried replacing Thread.currentThread().isInterrupted() in the checkInterruptedStatus() method in your test case with the following, and the test passed - the interruption was seen. This seems to be different to your result below using interrupted(). This is using 7u9, both 32- and 64-bit.

    private boolean checkInterruptedStatus() {
        return Thread.interrupted();
    }

I can reproduce the original version of your test case on 7u9 64-bit *but not 32-bit*.

Thanks,
Joe

From: concurrency-interest-bounces at cs.oswego.edu<mailto:concurrency-interest-bounces at cs.oswego.edu> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Dr Heinz M. Kabutz
Sent: 08 November 2012 06:11
To: Vitaly Davidovich
Cc: concurrency-interest at cs.oswego.edu<mailto:concurrency-interest at cs.oswego.edu>
Subject: Re: [concurrency-interest] _interrupted field visibility bug in OpenJDK 7+

Thanks for picking it up, Aleksey.

One more point - originally the short test method looked like this:

private void interrupted() throws InterruptedException {
    if (Thread.interrupted()) throw new InterruptedException();
}

That also did not throw the exception.

Heinz

On 11/8/12 3:01 AM, Vitaly Davidovich wrote:

I understand, I was just surprised that this is not an enregistering problem - this code isn't rereading the value from a register, it's not re-reading it at all from the assembly you pasted.

Sent from my phone
On Nov 7, 2012 7:33 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com<mailto:aleksey.shipilev at oracle.com>> wrote:
This is still a bug; the checking for safepoint guarantees this thread
is responding to VM stop events, but not particularly to interrupt
events. The dissasembly for the plain
Thread.currentThread().isInterrupted()-checking loop rechecks the
interrupt flag as fine.

-Aleksey.

On 11/07/2012 06:44 PM, Vitaly Davidovich wrote:
> So looks like nothing to do with hoisting, eh? It simply enters a busy
> loop checking for safe points?
>
> Sent from my phone
>
> On Nov 7, 2012 6:30 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com<mailto:aleksey.shipilev at oracle.com>
> <mailto:aleksey.shipilev at oracle.com<mailto:aleksey.shipilev at oracle.com>>> wrote:
>
>     On 11/07/2012 06:19 PM, Aleksey Shipilev wrote:
>     > On 11/07/2012 05:00 PM, Dr Heinz M. Kabutz wrote:
>     >> As I said, the original code was more involved, but this demonstrates
>     >> the essentials.  I hope some of you might be able to take a look at
>     >> what's going on.
>     >
>     > Successfully reproduced the failure on JDK 7u7, Linux x86_64:
>     >   java version "1.7.0_07"
>     >   Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
>     >   Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
>     >
>     > Tests passes with -XX:-Inline. Will look at more detail shortly.
>
>     This seems to be the miscompilation indeed:
>
>     # {method} 'think' '()V' in 'InterruptedVisibilityTest'
>       ...
>       0x00007f31890601a3: mov    0x14(%r10),%r11d      // read $interrupted
>       0x00007f31890601a7: test   %r11d,%r11d           // test $interrupted
>       0x00007f31890601aa: jne    0x00007f31890601c9    // exit branch
>       0x00007f31890601ac: mov    %rbp,%r10             // LOOP START
>       0x00007f31890601af: test   %eax,0xb15ee4b(%rip)  // safepoint
>       0x00007f31890601b5: jmp    0x00007f31890601ac    // LOOP END
>
>     Will raise the appropriate issue against OpenJDK once I finish with a
>     quick errand here. Thanks for the test case!
>
>     -Aleksey.
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
>     <mailto:Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

This email and any files transmitted with it contain confidential and proprietary information and is solely for the use of the intended recipient.  If you are not the intended recipient please return the email to the sender and delete it from your computer and you must not use, disclose, distribute, copy, print or rely on this email or its contents.  This communication is for informational purposes only.  It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction.   Any comments or statements made herein do not necessarily reflect those of GSA Capital. GSA Capital Partners LLP is authorised and regulated by the Financial Services Authority and is registered in England and Wales at Stratton House, 5 Stratton Street, London W1J 8LA, number OC309261. GSA Capital Services Limited is registered in England and Wales at the same address, number 5320529.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121108/1c684d56/attachment-0001.html>


More information about the Concurrency-interest mailing list