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