[10] RFR: JDK-8160354: uninitialized value warning and VM crash are occurred with GCC 6

[Kim Barrett]

> On May 23, 2017, at 8:38 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
> 
> Hi Kim,
> 
> On 2017/05/23 18:47, Kim Barrett wrote:
>>> On May 23, 2017, at 4:27 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I've posted review request [1].
>>> I want to resume to work about it.
>>> 
>>> This issue is marked as P3 bug [2].
>>> I uploaded the webrev for jdk 10. Could you review it?
>>> 
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160354/webrev.02/
>>> 
>>> I cannot access JPRT.
>>> So I need a sponsor.
>>> 
>>> 
>>> Thanks,
>>> 
>>> Yasumasa
>>> 
>>> 
>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023658.html
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8160354
>> 
>> As discussed in the CR, I think this is closely related to
>> JDK-8160404.  I think the change to the RelocationHolder constructor
>> being suggested here may be just papering over a symptom of that other
>> bug.
> 
> Will the change of JDK-8160404 initialize _relocbuf in RelocationHolder constructor?
> IMHO all C++ class member should initialize before reading, and c'tor is useful for it.

I don’t know exactly how JDK-8160404 will be fixed.  I think it will involve initializing
at least some of the elements of _relocbuf in a more obvious way that should be visible
to the compiler. I’m not sure the trailing elements need to be initialized, and it would be
wasteful to unconditionally fill with zeros and then overwrite the prefix.

Let’s see what comes out of work on JDK-8160404.

>> And I suspect that if JDK-8160404 were fixed then there wouldn't be
>> any warnings in make_raw to be addressed in what looks to me like a
>> kludgy workaround.
> 
> I don't know how to fix it in JDK-8160404.
> Should I wait to fix JDK-8160404?

Someone else is working on JDK-8160404.  I think a fix for it ought to solve this one too.