discuss about release barrier for final fields initialization

[Wei Kuai]

Hi Andrew,
  I tested "dmb.ishst; dmb.ishld" for release barrier. The test case is jmh
of allocation with final fields.
https://gist.github.com/kuaiwei/f71fba40df29991c93325a8600e34c13
In N1
  dmb.ish                    : 1168.059 ops/s
  dmb.ishst+dmb.ishld: 1321.783 ops/s
  dmb.ishst                 : 1511.267 ops/s
In N2
  dmb.ish                    : 3672.087 ops/s
  dmb.ishst+dmb.ishld: 4840.322 ops/s
  dmb.ishst                 : 6005.430 ops/s

The "dmb.ishst+dmb.ishld" can gain 13% and 32% on N1 and N2. It looks a
better replacement for "dmb.ish"

Thanks,
Kuai Wei

On Wed, Jan 17, 2024 at 10:49 PM Andrew Haley <aph-open at littlepinkcloud.com>
wrote:

> On 1/11/24 11:58, Kuai Wei wrote:
> > Thanks for reply. I checked the previous discussion and not clear about
> the root cause.
> >
> > If you can provide more detail about the optimize, like what load or
> load dependency will be elided, so we may check chance to detect or prevent.
>
> We think you're probably right. However, C2 does a lot of reorganization,
> so it's hard to say that C2 can never predict what might be stored by
> static field initialization in one thread.
>
> If you're benchmarking this, can you try dmb st; dmb ld without fusing
> them together, thus avoiding a storeload? This would help us understand
> the performance benefit.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20240118/0a3aec22/attachment.htm>