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

[Aleksey Shipilev]

Hi Vladimir!

New webrev:
 http://cr.openjdk.java.net/~shade/8146801/webrev.05/

On 03/01/2016 04:01 AM, Vladimir Kozlov wrote:
> I was thinking may be we should do it in Ideal graph instead of
> assembler. But it could trigger Fill array or split iterations
> optimizations which may not good for such small arrays.

Yes, I thinking about that too, but backed off thinking this is a
x86-specific optimization. But then again, looking at ClearArray::Ideal
that happens for all platforms, we should try to emit the runtime check
there too. Let me see if we can pull that off without messing up the
generated code. Meanwhile, the webrev above is the assembler-side variant.

> Did CPU, you tested on, supports ERMS (fast stos)?

Yes, tested on i7-4790K (Haswell), /proc/cpuinfo reports "erms", and we
are going through UseFastStosb branch.

> clear_mem() is used only in .ad which is only C2. You can put it under
> #ifdef COMPILER2 and you can access Matcher::init_array_short_size then.

Ah, good trick. Still, I think exposing this as the true
platform-dependent flag is better. It also closely follows what
ClearArray::Ideal does.

> Why x86_32.ad does not have similar changes?

Hm, I thought I uploaded the webrev with those changes too, but now I
see it is missing. A new webrev has x86_32 parts.

> Do we really should care for old CPUs (UseFastStosb == false)?

I think we should care, in the same way we care in ClearArray::Ideal.

> Use short branch instructions jccb and jmpb!!!!

> movptr(Address(base, cnt, Address::times_ptr), 0); is too big. You have
> RAX for that.

> Labels declaration (except DONE) and bind(LONG); should be inside if
> (!is_large) { since it is only used there.

*embarrased* All three fixed in new webrev.

> You have too many jumps per code. I would suggest next:

The variant of your code is in new webrev (there were two minor bugs:
shlptr was too late for 32-bit VMs, and no jmpb(DONE)).



Thanks,
-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/be761f32/signature.asc>