RFR: 8155638: Resource allocated BitMaps are often cleared twice

Nils Eliasson nils.eliasson at oracle.com
Thu Jun 2 08:04:45 UTC 2016


Hi Stefan,

I prefer the reinitialize alternative in c1_linearscan.cpp. Please use 
that version.

Reviewed.

Thanks for fixing this!
Nils


On 2016-05-06 12:46, Stefan Karlsson wrote:
> 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/20160602/707ec7c2/attachment.html>


More information about the hotspot-compiler-dev mailing list