JDK-8156207 : Resource allocated BitMaps are often cleared unnecessarily
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,12,13,14
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-05-06
  • Updated: 2020-06-16
  • Resolved: 2019-07-29
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 11 JDK 13 JDK 14
11.0.8-oracleFixed 13.0.4Fixed 14 b08Fixed
Related Reports
Relates :  
JDK-8155638 - Resource allocated BitMaps are often cleared twice
Description
This bug relates to JDK-8155638 where bitmaps where cleared twice.

There are places where we don't clear the bitmaps twice, but the initial clearing is unnecessary, since the following code will set all bits.

See, for example:
http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/c1/c1_IR.cpp.udiff.html

where _requires_phi_function is cleared even when all bits are going to be set to 1.

and:
http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/compiler/methodLiveness.cpp.frames.html

in MethodLiveness::BasicBlock::get_liveness_at

1010   ResourceBitMap g(_gen.size()); g.set_from(_gen);
1011   ResourceBitMap k(_kill.size()); k.set_from(_kill);

where we first clear the bitmap, then copy all bits with set_from. Before G1 was introduced, the unnecessary clearing was not done.
Comments
Fix request (13u): I would like to backport this fix to 13u for parity with 11u. The original change applies cleanly.
08-06-2020
jdk11 backport request I would like to have the patch in OpenJDK11 as well (for better parity with 11.0.8_oracle). The patch applies cleanly.
14-05-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/1fec2d70fa13 User: thartmann Date: 2019-07-29 07:40:28 +0000
29-07-2019
http://cr.openjdk.java.net/~thartmann/8156207/webrev.00/
26-07-2019
Should we simply close this one as "not an issue"? -- The code in "methodLiveness.cpp" is: #ifdef ASSERT ResourceMark rm; ResourceBitMap g(_gen.size()); g.set_from(_gen); ResourceBitMap k(_kill.size()); k.set_from(_kill); #endif (this seems to be the only such occurrence of the above pattern) Alternatively, apply something like (exposing the underlying conditional clear operation): -----8<----- modified src/hotspot/share/utilities/bitMap.hpp - ResourceBitMap(idx_t size_in_bits); + ResourceBitMap(idx_t size_in_bits, bool clear = true); modified src/hotspot/share/utilities/bitMap.cpp -ResourceBitMap::ResourceBitMap(idx_t size_in_bits) - : BitMap(allocate(ResourceBitMapAllocator(), size_in_bits), size_in_bits) { +ResourceBitMap::ResourceBitMap(idx_t size_in_bits, bool clear) + : BitMap(allocate(ResourceBitMapAllocator(), size_in_bits, clear), size_in_bits) { modified src/hotspot/share/compiler/methodLiveness.cpp - ResourceBitMap g(_gen.size()); g.set_from(_gen); - ResourceBitMap k(_kill.size()); k.set_from(_kill); + ResourceBitMap g(_gen.size(), false); g.set_from(_gen); + ResourceBitMap k(_kill.size(), false); k.set_from(_kill);
08-07-2019
Hi Rickard, could you please investigate this issue? (I thought of you because you are close to Stefan and can discuss possible issues). Thank you! Best regards, Zoltan
21-02-2017
ILW = Possible performance regression, during compilation, no workaround = LMH = P5
20-02-2017
I=possible performance regression=L=>LMH=>P5
30-05-2016
Changing back to bug. This is an regression.
19-05-2016