JDK-8244162 : Additional opportunities to use NONCOPYABLE
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-04-30
  • Updated: 2021-07-19
  • Resolved: 2021-07-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18 b06Fixed
Related Reports
Duplicate :  
Relates :  
Description
While backporting JDK-8234779 I noticed a handful of additional cases where the NONCOPYABLE macro should probably be applied. For example, in src/hotspot/share/utilities/formatBuffer.hpp.

I think the best way to identify any remaining cases like this is to manually examine every place where a copy constructor is declared. This approach is practical as there only seems to be about 30 copy constructors in mainline at the moment. I believe something like the following search should catch all of them:

===
find . -name "*.hpp" |xargs grep -E '\b(\w+)\s*[\(]\s*(const)*\s*(volatile)*\s*\1\s*[&]\s*\w*\s*[\)]'
===

We should look at each result one-by-one and determine if the author was trying to prevent copying. We can replace these cases with the NONCOPYABLE macro where appropriate.
Comments
Changeset: 92ae6a51 Author: Harold Seigel <hseigel@openjdk.org> Date: 2021-07-12 14:21:44 +0000 URL: https://git.openjdk.java.net/jdk/commit/92ae6a512340485f75a12479dc1c1b8d3261bc76
12-07-2021