RFR: 8314488: Compile the JDK as C++17 [v2]

[Kim Barrett]

On Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-7
>>  - Revert vm_version_linux_riscv.cpp
>>  - vm_version_linux_riscv.cpp
>>  - allocation.cpp
>>  - 8310260
>
> I agree that before throwing this switch, we need to look at some specific
> issues that might need to be addressed, discuss the benefits, and also the
> costs.
> 
> As was discussed for the change to C++14, there is *never* a good time to
> start introducing the use of new language features as far as backporting is
> concerned, unless one is going to backport the language change too. We didn't
> do that for C++14, and I don't think we are going to (nor should) do it for
> C++17 either.  But backporting concerns can't be all powerful, as that will
> forever prevent potentially significant improvements.
> 
> I started to make a list of new language features that seem particularly
> beneficial or otherwise important.  I was going to write style guide updates
> for these, but haven't gotten very far with that yet.
> 
> P0035R4: Dynamic memory allocation for over-aligned data
> P0135R1: Guaranteed copy elision
> P0145R3: Refining Expression Evaluation Order for Idiomatic C++
> P0292R2: constexpr if
> P0091R3/P0512R0: Template argument deduction for class templates
> 
> Here are some others that might be of interest to us.
> N4268: Allow constant evaluation for all non-type template arguments
> N3928: Extending static_assert
> P0118R1: [[fallthrough]] attribute
> P0189R1: [[nodiscard]] attribute
> P0212R1: [[maybe_unused]] attribute
> P0170R1: Wording for constexpr lambda
> P0283R2: Ignoring unsupported non-standard attributes 
> P0061R1: __has_include for C++17
> P0386R2: Inline variables

> @kimbarrett
> 
> > P0035R4: Dynamic memory allocation for over-aligned data
> 
> Do we really need this? I ask because, in the end, this will result in something like `posix_memalign` to be called, and I remember it being notorious for causing large footprint overhead depending on how smart the underlying allocator is about using alignment waste.
> 
> It will also be non-trivial to implement in hotspot since NMT uses malloc headers. Barring a rewrite of NMT malloc metadata tracking (e.g. using a hash map, which would be more costly both in terms of performance and, probably, footprint), malloc headers would have to be revised. Probably would need to be dynamic-sized. This is the reason we did not bother wrapping posix_memalign.

We already have code that (incorrectly) expects dynamic allocation to support
overalignment. There are several classes that overalign (often cache align) a
member to avoid false sharing, but are dynamically allocated. See most (all?)
uses of ZCACHE_ALIGNED for some examples.

One way to fix this would be to give those classes their own operator new to
perform aligned allocation somehow. That's what was done for
OopStorage::Block, but it's clumsy and likely wasteful of memory. And it's
easy to forget. A general solution would probably be better. But yes, NMT
malloc headers certainly make the general problem challenging. The approach
currently used for OopStorage::Block can be generalized and hooked into the
standard mechanism.  But maybe there are (possibly non-portable) alternatives
that avoid the memory waste?

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1864375915