On Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett <kbarr...@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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1864039399
