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]

Hi Goetz,

Thank you for the patch.  I am working on final testing for this, but 
probably won't have the fix in review until next week due to being out 
of the office tomorrow and Friday.  The open problem report is 
JDK-8048128 <https://bugs.openjdk.java.net/browse/JDK-8048128>.

Lois

On 6/24/2014 7:41 AM, Lindenmaier, Goetz wrote:
> Hi Lois,
>
> great if you fix that.  I would do it too, but I anyways need a sponsor
> to push the change, and you should test it, too, I guess.
>
> The patch that does the fix for ppc is below.
>
> Best regards,
>    Goetz.
>
>
> --- a/src/share/vm/oops/oopsHierarchy.hpp       Thu Jun 19 13:31:14 2014 +0200
> +++ b/src/share/vm/oops/oopsHierarchy.hpp       Tue Jun 24 13:39:07 2014 +0200
> @@ -124,7 +124,7 @@
>     operator oopDesc* () const volatile { return obj(); }
>     operator intptr_t* () const         { return (intptr_t*)obj(); }
>     operator PromotedObject* () const   { return (PromotedObject*)obj(); }
> -  operator markOop () const           { return markOop(obj()); }
> +  operator markOop () const volatile  { return markOop(obj()); }
>     operator address   () const         { return (address)obj(); }
>
>     // from javaCalls.cpp
>
>
>
>
> -----Original Message-----
> From: Lois Foltan [mailto:lois.foltan at oracle.com]
> Sent: Montag, 23. Juni 2014 21:20
> To: Lindenmaier, Goetz
> Cc: hotspot-runtime-dev
> Subject: Re: 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
>
>
> 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