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