RFR (S) 8146801: Allocating short arrays of non-constant size is slow
Aleksey Shipilev
aleksey.shipilev at oracle.com
Mon Feb 29 21:02:47 UTC 2016
Hi,
Object storage zeroing uses "rep stos" instructions on x86, which are
fast on long lengths, but have the setup penalty. We successfully avoid
that penalty when zeroing the objects of known lengths (all objects and
arrays of constant sizes). However, we don't do anything for arrays of
non-constant sizes, which are very frequent.
See more details here:
https://bugs.openjdk.java.net/browse/JDK-8146801
Patch:
http://cr.openjdk.java.net/~shade/8146801/webrev.02/
The core of the changes is at MacroAssembler::clear_mem.
The rest is collateral:
a) pulling InitArrayShortSize from Matchers to global VM options to
get the access to it in MacroAssembler;
b) dragging ClearArrayNode::_is_large when ClearArrayNode::Ideal bails
on large constant length -- otherwise we produce effectively dead code
for short loop in MacroAssembler, that is never taken.
With this patch, the allocation performance for small arrays is improved
3-4x. Performance data and disassemblies:
http://cr.openjdk.java.net/~shade/8146801/notes.txt
Testing: JPRT -testset hotspot; targeted microbenchmarks; RBT
hotspot/test/:hotspot_all,vm.runtime.testlist,vm.compiler.testlist
Cheers,
-Aleksey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160301/0778c02d/signature.asc>
More information about the hotspot-compiler-dev
mailing list