RFR: 8229258: Make markOopDesc AllStatic

[Roman Kennke]

> On 2019-08-08 12:22, Roman Kennke wrote:
>> First glance.
>>
>> Instead of making it AllStatic, I'd probably have made it a plain object:
>>
>> class markWord {
>> }
>>
>> and instead of changing e.g.:
>>
>> obj->mark().set_unlocked();
>>
>>   to
>>
>> MarkWord::set_unlocked(obj->mark());
>>
>> leave it like it is. Looks/feels better to me.
>>
>> Have you tried that? Is this too tricky to do? Or what is the reason to
>> use static accessors there?
> 
> Not sure if you mean that we should still play tricks with the this
> pointer. If that's the case then, that would retain the undefined
> behavior that this patch removes (by using the static accessors). One
> example given below is:
> 
> bool is_being_inflated() const { return (value() == 0); }
> 
> which ends up comparing this to NULL.

Eww, no, this doesn't seem right.

> But maybe you suggests adding the mark word bits as a value in MarkWord?
> Something like this:
> 
> class MarkWord {
>   uintptr_t _value;
> 
>   // and keep the functions as non-static functions
>   bool is_being_inflated() const { return (_value == 0); }
> }   
> 
> then, yes, I tried that because I also felt that it was unfortunate that
> I had to retransform the code in this way. However, I backed off because
> of different hurdles that I couldn't trivially solve. For example:
> 
> class oopDesc {
>   volatile markWord _mark;
> }
> ...
> _mark = prototype(); <-- complains here that the assignment operator
> discards volatile qualifier
> 
> I'm unsure what performance effects it will have if I provide a
> hand-written assignment operator, since the class will not be a trivial
> class anymore. Because of that, I backed away from such a change.
> 
> I'm not at all opposed to wait with this patch if someone wants to take
> the time to retry that experiment.

Yeah, that was what I had in mind, but if it's too complicated then it's
ok to do AllStatic access.

Give me some time to review the rest of the patch.

Thanks
Roman