Fwd: Improve large array allocation / gc & intrinsics

[Laurent Bourgès]

Please, could you give me your opinions on the following ideas for a JDK9
RFE ?

Is it worth? Interesting or totally stupid with current hotspot / gc ?

How hard / long would it be to study and make a prototype ?

Any other ideas to improve array performance like improving again the array
bound check elimination or fill / clear intrinsics ...

Who would be interested by this topics ?

Laurent

---------- Message transféré ----------
De : "Laurent Bourgès" <bourges.laurent at gmail.com>
Date : 10 févr. 2014 10:24
Objet : Improve large array allocation / gc & intrinsics
À : "core-libs-dev" <core-libs-dev at openjdk.java.net>, "discuss" <
discuss at openjdk.java.net>
Cc :

> Dear all,
>
> I would like to propose a JDK9 RFE to improve JVM efficiency when
> dealing with large arrays (allocation + gc).
>
> In several scientific applications (and my patched java2d pisces),
> many large arrays are needed, created on the fly and it becomes very
> painful to recycle them using an efficient array cache (concurrency,
> cache size tuning, clear + cache eviction issues).
>
> In this case, the GC overhead leads to a big performance penalty
> (several hundred megabytes per seconds).
>
> As such array cache are very efficient in an application context, I am
> wondering if that approach could be promoted at the JDK level itself:
>
> - provide a new array allocator for large arrays that can return
> larger arrays than expected (size = 4 or 8 multiples) using array
> caches (per thread ?) stored in a dedicated JVM large memory area (GC
> aware) and providing efficient cache eviction policies
>
> - may support for both clean arrays (zero filled) or dirty arrays
> because some algorithms does not need zero-filled arrays.
>
> - improve JVM intrinsics (array clear, fill) to achieve maximum
> performance ie take into account the data alignment (4 or 8 multiples)
>
> - upgrade GC to recycle such 'cached' arrays (clean), update usage
> statistics and manage cache eviction policy (avoid wasting memory)
>
> Please give me your feedback & opinion and evaluate if this feature
> seems possible to implement into the JDK (hotspot, gc, core-libs) ...
>
> What is the procedure to create such JDK9 RFE ?
>
> Best regards,
>
> Laurent Bourgès
 ---------- Message transféré ----------
De : "Laurent Bourgès" <bourges.laurent at gmail.com>
Date : 10 févr. 2014 10:24
Objet : Improve large array allocation / gc & intrinsics
À : "core-libs-dev" <core-libs-dev at openjdk.java.net>, "discuss" <
discuss at openjdk.java.net>
Cc :

Dear all,
>
> I would like to propose a JDK9 RFE to improve JVM efficiency when
> dealing with large arrays (allocation + gc).
>
> In several scientific applications (and my patched java2d pisces),
> many large arrays are needed, created on the fly and it becomes very
> painful to recycle them using an efficient array cache (concurrency,
> cache size tuning, clear + cache eviction issues).
>
> In this case, the GC overhead leads to a big performance penalty
> (several hundred megabytes per seconds).
>
> As such array cache are very efficient in an application context, I am
> wondering if that approach could be promoted at the JDK level itself:
>
> - provide a new array allocator for large arrays that can return
> larger arrays than expected (size = 4 or 8 multiples) using array
> caches (per thread ?) stored in a dedicated JVM large memory area (GC
> aware) and providing efficient cache eviction policies
>
> - may support for both clean arrays (zero filled) or dirty arrays
> because some algorithms does not need zero-filled arrays.
>
> - improve JVM intrinsics (array clear, fill) to achieve maximum
> performance ie take into account the data alignment (4 or 8 multiples)
>
> - upgrade GC to recycle such 'cached' arrays (clean), update usage
> statistics and manage cache eviction policy (avoid wasting memory)
>
> Please give me your feedback & opinion and evaluate if this feature
> seems possible to implement into the JDK (hotspot, gc, core-libs) ...
>
> What is the procedure to create such JDK9 RFE ?
>
> Best regards,
>
> Laurent Bourgès
>