RFR (S) JDK-8041623: Solaris Studio 12.4 C++ 5.13, CHECK_UNHANDLED_OOPS use of class oop's copy constructor definitions causing error level diagnostic

[Lois Foltan]

On 6/23/2014 11:38 AM, Lindenmaier, Goetz wrote:
> Hi Lois,
>
> unfortunately, your change breaks the ppc build (with gcc 4.1.2):
>
> collectedHeap.inline.hpp:85 In function "void post_allocation_notify(KlassHandle, oop, int)":
> collectedHeap.inline.hpp:85: warning: choosing "oop::operator markOopDesc*() const" over "oop::operator oopDesc*() const volatile"
> collectedHeap.inline.hpp:85: warning:   for conversion from "oop" to "oopDesc*"
> collectedHeap.inline.hpp:85: warning:   because conversion sequence for the argument is better
>
> This is because you added 'volatile' to the operator definition of the oopDesc call.
>
> This can be fixed by adding 'volatile' to the markOop cast operator.
> Would that be fine with you, or will it break your case?  If so, I'll make the
> corresponding change.

Hi Goetz,

My apologies about this.  You suggested fix seems reasonable and I have 
completed a test build with Solaris C++ 5.13 and on Linux with g++ 
4.4.4.  I will open a JDK bug and get this fixed on our end.

Thanks,
Lois

>
> Best regards,
>    Goetz
>
>
>
> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Lois Foltan
> Sent: Donnerstag, 22. Mai 2014 19:41
> To: hotspot-runtime-dev
> Subject: RFR (S) JDK-8041623: Solaris Studio 12.4 C++ 5.13, CHECK_UNHANDLED_OOPS use of class oop's copy constructor definitions causing error level diagnostic
>
> Hello,
>
> Please review the following fix:
>
> Webrev:
>       http://cr.openjdk.java.net/~lfoltan/bug_jdk8041623/
>
> Bug: Solaris Studio 12.4 C++ 5.13, CHECK_UNHANDLED_OOPS use of class
> oop's copy constructor definitions causing error level diagnostic
>       https://bugs.openjdk.java.net/browse/JDK-8041623
>
> Summary of fix:
> A couple of fixes for Solaris C++ 5.13 compilation issues specifically
> related to CHECK_UNHANDLED_OOPS support in non-product JVM builds.
> First, the following diagnostic occurred concerning a volatile oop being
> returned by value.  C++ complained that the return value failed to
> correctly copy construct into a temporary when returning from
> target_volatile().
>
> "javaClasses.hpp", line 1183: Error: Initializing const volatile oop&
> requires an lvalue.
> "javaClasses.hpp", line 1183: Error: Formal argument o of type const
> volatile oop& in call to oop::oop(const volatile oop&) is being passed
> volatile oop.
>
> The fix required a user conversion from oop to OopDesc* with immediate
> oop construction to provide the lvalue needed.  Solaris C++ 5.13 also
> complained about the lack of an appropriate assignment operator from
> NULL to volatile oop.  Solution was to explicitly construct NULL prior
> to assignment.
>
> Built with the following versions:
>       carrs: g++ 4.4.3
>       crocker: g++ 4.4.4
>       philli: g++ 4.8.1
>       Solaris C++ 5.10 (12u1)
>       Solaris C++ 5.12 (12u3)
>       Solaris C++ 5.13 - beta
> VS2013
>
> Tests:
>       JPRT build & test,
>       Hotspot jtreg on Solaris,
>       Hotspot jtreg on Linux with -XX:+CheckUnhandledOops,
>       vm.quick.testlist - 2 runs one with -XX:+CheckUnhandledOops and one
> without
>
> Thank you,
> Lois