RFR: 8330047: ASAN build error with gcc 13

Kim Barrett kbarrett at openjdk.org
Fri Apr 19 03:43:56 UTC 2024


On Thu, 18 Apr 2024 18:39:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I don't think this change should be made. There are two problems exhibited by the current code. One is that ASAN doesn't seem to properly handle alignas attributes. The other is that we're misusing alignas attributes. Fixing the latter would both eliminate the resulting UB and work around the ASAN bug.
> 
> Could you elaborate on the misusing?

[This is summarizing the relevant part of an Oracle-internal discussion about
JDK-8330047 from earlier this week that hasn't yet made it to the JBS issue.]

ZMarkStripe is one of several classes with over-aligned members, via
ZCACHE_ALIGNED. As a result, these classes have over-aligned alignment
requirements. Several of these classes are (indirect) members of
ZCollectedHeap, with the result that it too has an over-aligned alignment
requirement. But there is no code (*) to ensure the allocation of the
ZCollectedHeap instance actually meets that alignment requirement.  And an
object must meet its alignment requirements; failure to do so is UB.

The places where ZCACHE_ALIGNED is being used are doing so to ensure there is
padding between members to avoid false sharing. Rather than using alignas (and
imposing alignment requirements that we don't currently meet and don't
actually need) to cause such padding to be inserted, we should instead insert
padding directly, using the facilities in memory/padded.hpp.

(*) C++17 provides a mechanism for heap allocation of over-aligned types, but
(1) we're not yet using C++17, and (2) we might not implement support for
over-aligned NMT-based heap allocation.

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

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


More information about the hotspot-gc-dev mailing list