RFR: 8155638: Resource allocated BitMaps are often cleared twice

Stefan Karlsson stefan.karlsson at oracle.com
Fri May 6 10:46:57 UTC 2016


Hi all,

Please review this patch to remove some redundant clearing of bitmaps.

http://cr.openjdk.java.net/~stefank/8155638/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8155638


It used to be the case that Resource allocated bitmaps were _not_ 
cleared in the constructor, and that explicit calls to clear() were 
needed. However, when G1 was open sourced all the Resource allocated 
bitmaps were always cleared in the BitMap constructor:

http://hg.openjdk.java.net/jdk9/hs/hotspot/diff/37f87013dfd8/src/share/vm/utilities/bitMap.cpp


It's apparent that the lazy clearing of bitmaps was used to skip 
clearing when it wasn't necessary.

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.

I've created a new CR for these kind of issues:

https://bugs.openjdk.java.net/browse/JDK-8156207 - Resource allocated 
BitMaps are often cleared unnecessarily


During the review of "8141501: Problems with BitMap buffer management", 
I got the request do the following change:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/022969.html

I tried it, but felt that the change didn't fit the surrounding code, 
where shallow-copying was used for other bitmaps. It would be great if 
reviewers of this patch could decide if I should change the code as 
suggested.


Thanks,
StefanK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160506/bdd2b6b2/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list