Stack allocation prototype for C2

[Charlie Gracie]

Hi Sergey,

We have some old data but we will gather new data for the benchmarks showing wins on overall allocation reduction. I attempted to gather this data yesterday but I ran into an issue with JFR. I have a work-around so we should be able to get the data in the next couple of days. With the holidays in Canada and the US this week it might take until Monday to get the data together. 

One of the common places we see wins is with Scala iterators, in particular, when iterating over primitive arrays. Regularly the array elements get boxed to perform an operation. I believe in the Scala TMT benchmark the win is removing an allocation of boxed Double objects when iterating over an array.

Thanks for the question and we will get back to you with the data soon.
Charlie

On 2020-06-29, 11:34 PM, "hotspot-compiler-dev on behalf of Sergey Kuksenko" <hotspot-compiler-dev-retn at openjdk.java.net on behalf of sergey.kuksenko at oracle.com> wrote:

    I am just curious.
    
    For each benchmark you show allocation reduce size in general. Do you 
    have statistics which stack allocated objects gives major impact? And 
    which code patterns fail scalar replacement except well know Integer 
    cache flow merge?
    
    On 6/29/20 2:05 PM, Charlie Gracie wrote:
    > Hi hotspot-compiler-dev community,
    >
    > Here is the prototype code for our work on adding stack allocation to the HotSpot C2 compiler. We are looking for any and all feedback
    > as we hope to move from a prototype to something that could be contributed. A change of this size is difficult to review so we
    > understand the process will be thorough and will take time to complete. Any suggestions on how to allow for collaboration with others,
    > if they wanted to, would also be appreciated (i.e., a repo somewhere).
    >
    > For a quick refresher here is a link to Nikola’s talk at FOSDEM:
    > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffosdem.org%2F2020%2Fschedule%2Fevent%2Freducing_gc_times%2F&data=02%7C01%7Ccharlie.gracie%40microsoft.com%7C9e9b56c23fde463bf6b808d81ca68bf4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290848926541670&sdata=qB1c8l5mUVk%2BAt7W5178A9wQ3pauoxW6XTVCfOTOmHw%3D&reserved=0
    >
    > Here is a link to our initial webrev:
    > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fcharlie%2Fstack_alloc%2F&data=02%7C01%7Ccharlie.gracie%40microsoft.com%7C9e9b56c23fde463bf6b808d81ca68bf4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290848926541670&sdata=46mF34J4XcMV58TJxvJ4%2FiDSxL41TSKgW0X2MX7HRV4%3D&reserved=0
    >
    > Expecting that a change like this will require a JEP, we have prepared a document describing our work based off of the JEP submission
    > form. Our document has a few extra sections at the end discussing areas that we are looking for guidance on and some initial
    > performance results. This document can be found here:
    > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-proposals%2Fblob%2Fmaster%2Fstack_allocation%2FStack_Allocation_JEP.md&data=02%7C01%7Ccharlie.gracie%40microsoft.com%7C9e9b56c23fde463bf6b808d81ca68bf4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290848926541670&sdata=V%2BqKZ9QgCd%2BKDbFb9MqFDoxdtXm8fFmgh%2FLYxgiGqJA%3D&reserved=0
    >
    > Thanks in advance for reviews, suggestions, concerns, comments and issues.
    > Charlie and Nikola
    >