RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor
David Holmes
david.holmes at oracle.com
Tue Nov 17 01:30:30 UTC 2020
On 17/11/2020 9:25 am, Kim Barrett wrote:
> On Mon, 16 Nov 2020 21:12:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
>
>>> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`.
>>>
>>> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint.
>>>
>>> Testing:
>>> - GH actions
>>> - mach5 tiers 1-3
>>> - selected performance testing (guided by that used for JDK-8253064)
>>>
>>> Thanks,
>>> David
>>
>> I'm guessing that @dholmes-ora put it in initialize() because
>> it only needs to be checked once rather than every time the
>> table is used.
>
>>> The initialize() function is the wrong place. There's nothing in initialize that cares. The place for the assert is with the code that cares that it's a power of 2.
>>
>> As Dan indicated I put it there so that it is only checked once - no
>> point checking it on every use. Initialization code is often used to
>> check invariants.
>
> A static assert is checked once at compile time. And my opinion probably wouldn't be different if it were a runtime assert.
Okay I hadn't realized the static_assert was checked once at compile-time.
But isn't this assertion also checking it is a power of 2?
assert((NINFLATIONLOCKS & (NINFLATIONLOCKS-1)) == 0, "invariant");
Should I just replace that with the is_power_of_2() static assert?
Thanks,
David
-----
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1196
>
More information about the hotspot-runtime-dev
mailing list