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. 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
