RFR (S) 8146801: Allocating short arrays of non-constant size is slow

[Christian Thalinger]

> On Feb 29, 2016, at 11:02 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> 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;

+  product_pd(intx, InitArrayShortSize,                                      \

Don’t make it a product flag; diagnostic should be sufficient.  This will require adding diagnostic_pd support.  If you don’t want to do that make the flag develop.

>   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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160229/77689a2b/attachment-0001.html>