RFR: 8264707: HotSpot Style Guide should permit use of lambda

[Andrew Haley]

On Tue, 17 Aug 2021 13:49:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this proposal to permit the use of lambda expressions in
> HotSpot code, with some restrictions and suggestions for good usage within
> HotSpot code.  Lambda expressions were added in C++11, and provide a more
> expressive syntax for local functions, with a number of use-cases where they
> can improve readability by eliminating a lot of uninteresting boilerplate.
> 
> Some example uses are included, but are not part of the proposed change.
> They will be removed from the PR before it is pushed.  (In particular, the
> ScopeGuard utility uses move semantics, the use of which hasn't been
> approved or even discussed.)  They are given to show some of the benefits
> that might accrue from permitting the use of lambdas. In particular, they
> highlight some of the code reduction that is possible. Some of these code
> changes might be proposed in the future, using the normal PR process.
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change.  Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered.  A decision on this proposal will
> not be made before Wednesday 1-Sep-2021 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review
> process to approve (click on Review Changes > Approve), rather than sending
> a "vote: yes" email reply that would be normal for a CFV.

So here's an oink in the flightment:


macroAssembler_aarch64_aes.o: Error: Use of global operators new and delete is not allowed in Hotspot:
                 U operator delete(void*)
                 U operator new(unsigned long)
See: /Users/aph/theRealAph-jdk/make/hotspot/lib/CompileJvm.gmk



This happened on MacOS/AArch64, and was caused by an apparently innocuous Lambda. GCC doesn't generate new and delete for this construct, but AArch64 clang does for some reason. And I guess it's true that C++ compilers are free to do this, and even if one compiler doesn't do so today, it might tomorrow.

What should we do? At least for my application, it doesn't matter if new and delete are used, but in some cases it might. Do we need a blanket prohibition against new and delete, when the programmer has no control over it?

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

PR: https://git.openjdk.java.net/jdk/pull/5144