RFR: 8330047: ASAN build error with gcc 13

[Axel Boldt-Christmas]

On Wed, 17 Apr 2024 18:54:30 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all,
> 
> This PR addresses [8330047](https://bugs.openjdk.org/browse/JDK-8330047).
> 
> This is the workaround suggested in the comments. Might be worthwhile to include this patch as the recommended toolchain version for [building](https://openjdk.org/groups/build/doc/building.html) the JDK is currently gcc 13.2.0.
> 
> Testing: 
> - [x] Reproduced build failure with gcc 13.2.0.
> - [x] Verified release build is successful after patch with ```--enable-asan```. 
> 
> Thanks, 
> Sonia

This seems to be caused by a some bug in gcc, specifically in the interaction between `-fsanitize=address` and some optimisation pass which uses `memset` (or a similar construct). This bug can be seen without `alignas` all it requires is that for the last field `F` in and object of type `T` `offsetof(T, F) + sizeof(F) != sizeof(T)`.

This simple reproducer will  show the warnings when compiled with ` -fsanitize=address  -O3` and a `-std` `<= c++17`.  No warnings at `-O2` or below.
```C++
class A {
  double d;
  int i;
};

class B {
  A a[16];
  B();
};

B::B() : a() {
  for (int i = 0; i < 16; i++) {
    a[i] = A();
  }
}


d399b0903180bf9f5c31b8e142a2e7bc1b8e8763 handles this I believe by changing how this gets optimised. Another way of solving the compilation error would be to make  `offsetof(ZMarkStripe, _overflowed) + sizeof(_overflowed) == sizeof(ZMarkStripe)`.

The simples change to achieve this is the following:

-class ZStackList {
+class ZCACHE_ALIGNED ZStackList {


This over-aligns the type as well as the storage. And all uses (all storage) of `ZStackList` is currently marked with `ZCACHE_ALIGNED` so it will not change anything with regards to object layouts.

My suggestion is that we take my proposed change to parry for this gcc bug. 

_Some notes on the miss-aligned storage  UB:_

_As for the fact that `ZCollectedHeap` is allocated without being aligned (causing UB), this should be fixed as well but should be done separately. So we can keep using `alignas` instead of padding._ _As regardless of how it is done it tends to be more ugly and create more dependencies between nested classes (w.r.t. object layout). _

_Any over-aligned type (alignment `> 16`) will currently cause UB in `offset_of` as well.  For example, as with `ZCollectedHeap` when it gets registered with `VM_STRUCTS`._

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18825#issuecomment-2089615678