Avoid some GCC 10.X warnings in HotSpot

[Kim Barrett]

> On Jul 7, 2020, at 2:46 AM, Koichi Sakata <sakatakui at oss.nttdata.com> wrote:
> 
> Hi all,
> 
>>>> > https://bugs.openjdk.java.net/browse/JDK-8247818
> 
> Could we start addressing the issue (about GCC 10 build warnings)?
> 
> There is an unclear point as follows.In my opinion, that doesn't cause any problems if it is historical or an alignment issue. Mainly the reason is that the byte_at_put function is a private function.
> 
>>>>>> +  } else {
>>>>>> +    memcpy(_body, name, length);
>>>>>>    }
>>>>>>  }
>>>>> 
>>>>> So you are replacing byte_at_put with a memcpy call. On the surface
>>>>> that seems reasonable, but I have to wonder why we were using the
>>>>> loop in the first place. It may just be historical or it may relate
>>>>> to an alignment issue, or something else. Hopefully someone else
>>>>> (e.g. Coleen :) ) can shed more light here.

I've only looked at the HotSpot change (to symbol.[ch]pp), so only
JDK-8247818.  Presumably there should be another bug for the core-libs
issues. 

Using memcpy instead of byte_at_put (and getting rid of byte_at_put)
seems like a good idea to me.

However, the first two elements of _body are used by identity_hash().
That seems like a possible reason to force initialization of both
elements, which currently isn't done for length == 1.  But maybe it
doesn't matter that identity_hash isn't consistent between processes,
in which case forcing the initialization of _body[0] also shouldn't
be needed.