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.laur...@gmail.com> Date : 10 févr. 2014 10:24 Objet : Improve large array allocation / gc & intrinsics À : "core-libs-dev" <core-libs-dev@openjdk.java.net>, "discuss" < disc...@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.laur...@gmail.com> Date : 10 févr. 2014 10:24 Objet : Improve large array allocation / gc & intrinsics À : "core-libs-dev" <core-libs-dev@openjdk.java.net>, "discuss" < disc...@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 >
