RFR (S) JDK-8025004: -XX:+CheckUnhandledOops asserts for JDK 8 solaris sparc fastdebug binaries

[Daniel D. Daugherty]

On 10/2/13 10:38 AM, Lois Foltan wrote:
>
> Please review the following fix:
>
> Webrev:
>     http://cr.openjdk.java.net/~coleenp/bug_jdk8025004/

src/share/vm/oops/instanceKlass.hpp
     No comments.

src/share/vm/oops/instanceKlass.cpp
     No comments.

Thumbs up.

I realize that this particular instance of the compiler bug
is somewhat artificial because it is only tickled when the
CHECK_UNHANDLED_OOPS feature is used. However, my mind now
wonders if this compiler bug impacts other uses of volatile
in the VM and, if so, how do we detect it?

Also, the bug says 'solaris sparc'. Is there some reason that
this bug doesn't impact 'solaris x64'?

Dan


>
> Bug: -XX:+CheckUnhandledOops asserts for JDK 8 solaris sparc fastdebug 
> binaries
>     https://bugs.openjdk.java.net/browse/JDK-8025004
>
> Summary of fix:
>     This fix is to work around a Solaris Studio C++ 12u1 & 12u3 
> compiler bug. Basically in fastdebug builds
>     on Solaris, CHECK_UNHANDLED_OOPs is defined causing an oop to be 
> defined as a class instead of a oopDesc *.
>     Code within oops/instanceKlass.cpp defines several stack local 
> variables as "volatile oop init_lock". Solaris Studio C++
>     compilers erroneously call the oop's destructor twice for the 
> volatile oop upon exit from the code segment
>     within the member functions. Remove the keyword "volatile" from 
> all "init_lock" stack local variables defined
>     within oops/instanceKlass.cpp. This bug has been reported to the 
> Solaris Studio C++ compiler team.
>
> Tests:
>     JTREG, vm.quick.testlist on Solaris with -XX:+CheckUnhandledOops 
> specified
>
> Thank you, Lois
>
>