RFR: 8330047: ASAN build error with gcc 13

[Thomas Stuefe]

On Fri, 19 Apr 2024 03:40:28 GMT, Kim Barrett <kbarrett 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.

Ah, now I get it. Thank you!

I also now remember our discussion of over-aligned allocation. I guess we need have to crack that particular nut in NMT at some point if C++17 is coming closer.

I agree that using the correct padding would be correct for cases like this. I think we do the same thing with ObjectMonitor.

If we introduce padding with e.g. DEFINE_PAD_MINUS_SIZE, for cases like this where we use the default assignment operator, would this not mean the padding gets unnecessarily copied? Would, therefore, an operator like in @SoniaZaldana's PR here not be needed anyway?

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

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