RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor
David Holmes
david.holmes at oracle.com
Fri Aug 9 06:59:36 UTC 2019
On 9/08/2019 4:56 pm, Kim Barrett wrote:
>> On Aug 9, 2019, at 2:29 AM, David Holmes <david.holmes at oracle.com> wrote:
>> On 9/08/2019 4:03 pm, Kim Barrett wrote:
>>>>
>>>> Seems like the path of least resistance, and it's relatively easy to check that we don't assign a PlatformMonitor to a PlatformMutex field.
>>> Being noncopyable takes care of that.
>>
>> Noncopyable doesn't stop us from doing
>>
>> PlatformMutex m = new PlatformMonitor();
>>
>> though, does it?
>
> I’m not sure what potential problem you are trying to describe.
>
> That’s obviously not going to compile (unless PlatformMutex provided strange conversion
> constructors taking pointers, but there aren’t any of those).
>
> One can do
>
> PlatformMutex* m = new PlatformMonitor();
Yes sorry that is what I meant. :) Do the above then:
delete m;
and we get the destructor problem.
David
-----
> (unless the PlatformMutexBase approach is taken, in which case that doesn’t work).
>
>>>> but only PlatformMutex and PlatformMonitor, and those two are not assignment compatible and so we avoid the problem.
>>>>
>>>> That's not a terrible solution, but if you don't object strongly I'll stick with the current arrangement.
>>> I don’t think I can object strongly to things that are already pretty endemic in our code.
>>
>> I believe you can object strongly if you think we should be setting new standards of code cleanliness in new code. Though in that case we should get them codified in the style guide ASAP.
>
> Don’t really feel like taking that on right now.
>
More information about the hotspot-dev
mailing list