RFR: 8332042: Move MEMFLAGS to its own include file

Afshin Zafari azafari at openjdk.org
Sun May 12 17:54:03 UTC 2024


On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> MEMFLAGS, as well as its enum constants, should live in its own include. 
> 
> The constants are used throughout the code base, often without needing the allocation APIs exposed through allocation.hpp.
> 
> The MEMFLAGS enum def is often needed within NMT itself, again often without needing allocation.hpp.
> 
> ---
> 
> This patch moves the enum to its new file.
> 
> It fixes those `allocation.hpp` includes that where only needed to get MEMFLAGS. It does not fix other includes. 
> 
> For backward compatibility, until we straightened out the dependencies (e.g., fixing all places where we rely on indirect includes), I added memflags.hpp to allocation.hpp.
> 
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug crossbuild to aarch64, fastdebug minimal

src/hotspot/share/services/mallocLimit.hpp line 3:

> 1: /*
> 2:  * Copyright (c) 2023 SAP SE. All rights reserved.
> 3:  * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved.

Maybe 2023, 2024 instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19172#discussion_r1597683285


More information about the serviceability-dev mailing list