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

[Vitaly Davidovich]

Thanks Vladimir.

On Wednesday, March 2, 2016, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
wrote:

> I think it heavily depends on prefetch strategy:
>
>   product(intx,  AllocatePrefetchStyle, 1,
>           "0 = no prefetch, "
>           "1 = prefetch instructions for each allocation, "
>           "2 = use TLAB watermark to gate allocation prefetch, "
>           "3 = use BIS instruction on Sparc for allocation prefetch")
>
> Maybe prefetch distance and the number of prefetched lines is too much for
> small array allocations and it should be treated like an ordinary object
> allocation:
>
>       // Generate several prefetch instructions.
>       uint lines = (length != NULL) ? AllocatePrefetchLines :
> AllocateInstancePrefetchLines;
>       uint step_size = AllocatePrefetchStepSize;
>       uint distance = AllocatePrefetchDistance;
>
> But I'm not sure how much such optimization can buy us for the additional
> complexity in the code.

 Yes, I'm not sure either - was just a thought as intuitively it doesn't
make much sense to do the current amount of prefetch for such small
arrays.  Given the new code introduces a branch for small arrays,
piggybacking on that to elide prefetch seems kind of desirable.

 I've no idea whether it would matter in real code.  AFAIK, prefetchnta
will bring the line into L1 on modern Intel.  Prefetching beyond the
small array allocation would seem undesirable as it increases instruction
stream size for no benefit and may bring in lines that aren't needed at all.

Thanks

>
> Best regards,
> Vladimir Ivanov
>
> On 3/2/16 1:53 AM, Vitaly Davidovich wrote:
>
>> Related question - can the prefetch hints go away for small array
>> allocations considering size is already being branched on? I've noticed
>> allocations always come with a prefetch sequence, so perhaps this is
>> just standard allocation pattern.
>>
>> On Tuesday, March 1, 2016, Vladimir Kozlov <vladimir.kozlov at oracle.com
>> <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>>     Perfect!
>>
>>     Thanks,
>>     Vladimir
>>
>>     On 3/1/16 1:46 PM, Aleksey Shipilev wrote:
>>
>>         On 03/01/2016 08:03 PM, Vladimir Kozlov wrote:
>>
>>             Do you have new performance numbers? I hope it did not
>>             regress with new
>>             code.
>>
>>
>>         It does not regress, the code is tight:
>>         http://cr.openjdk.java.net/~shade/8146801/notes.txt
>>
>>             2 things left I fill should be addressed.
>>
>>
>>         Both are fixed here:
>>         http://cr.openjdk.java.net/~shade/8146801/webrev.06/
>>
>>         Still passes JPRT -testset hotspot; RBT run is in progress.
>>
>>         Cheers,
>>         -Aleksey
>>
>>
>>
>> --
>> Sent from my phone
>>
>

-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160302/e891e6bc/attachment-0001.html>