RFR(S, tedious): 8217250: Optimize CodeHeap Analytics

[Schmidt, Lutz]

Hi all, 
as said on Friday, I rebased the changeset to jdk/jdk and pushed it. The pushed version can be found at
  http://cr.openjdk.java.net/~lucy/webrevs/8217250.02/
It is identical to version 01 which was based on jdk12.
Thanks, 
Lutz 

On 18.01.19, 17:05, "Schmidt, Lutz" <lutz.schmidt at sap.com> wrote:

    Thank you, Tobias!
    
    As this enhancement will not make it into jdk12, I'll rebase it to jdk/jdk. I expect no conflicts and assume I can then push without further webrev/review. 
    
    Thanks,
    Lutz
    
    On 18.01.19, 10:49, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:
    
        Hi Lutz,
        
        looks good to me too.
        
        Best regards,
        Tobias
        
        On 17.01.19 19:39, Vladimir Kozlov wrote:
        > Looks good
        > 
        > Thanks,
        > Vladimir
        > 
        > On 1/17/19 7:47 AM, Schmidt, Lutz wrote:
        >> Hi Vladimir & all,
        >> there is a new webrev available: http://cr.openjdk.java.net/~lucy/webrevs/8217250.01/
        >> What's new (in addition to some comments) is the macro
        >>
        >>    // Flush the buffer contents if the remaining capacity is less
        >>    // than the calculated threshold (256 bytes + capacity/16)
        >>    // That should suffice for all reasonably sized output lines.
        >>    #define BUFFEREDSTREAM_FLUSH_AUTO(_termString)                \
        >>        BUFFEREDSTREAM_FLUSH_IF(_termString, 256+(_capacity>>4))
        >>
        >> It replaced the previous BUFFEREDSTREAM_FLUSH_IF("string", 512) occurrences.
        >> Regards,
        >> Lutz
        >>
        >> On 16.01.19, 22:53, "Vladimir Kozlov" <vladimir.kozlov at oracle.com> wrote:
        >>
        >>      On 1/16/19 12:37 PM, Schmidt, Lutz wrote:
        >>      > Hi Vladimir,
        >>      >
        >>      > thanks a lot for looking at this so quickly.
        >>      >
        >>      > Sure, I could declare a specialized "BUFFEREDSTREAM_FLUSH_512" for this. The "512"
        >> originated from the thought "its large enough for a well-behaved line and small enough to save
        >> some flushes".
        >>      >
        >>      > I was also thinking about a "BUFFEREDSTREAM_FLUSH_AUTO", where the spare space is derived
        >> from the buffer capacity, maybe something like 10 percent of the capacity, 256 bytes minimum. I
        >> wasn't sure if that could be categorized as over-engineered.
        >>           Yes, I think BUFFEREDSTREAM_FLUSH_AUTO is better than fixed size.
        >>           Vladimir
        >>           >
        >>      > Your thoughts?
        >>      >
        >>      > Thanks,
        >>      > Lutz
        >>      >
        >>      > On 16.01.19, 19:10, "hotspot-compiler-dev on behalf of Vladimir Kozlov"
        >> <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of vladimir.kozlov at oracle.com> wrote:
        >>      >
        >>      >      Hi Lutz,
        >>      >
        >>      >      I see that you have only one usage in all cases for:
        >>      >      BUFFEREDSTREAM_FLUSH_IF("", 512)
        >>      >
        >>      >      Can you simple declare simplified macro for this?
        >>      >
        >>      >      Otherwise looks good.
        >>      >
        >>      >      Thanks,
        >>      >      Vladimir
        >>      >
        >>      >      On 1/16/19 6:52 AM, Schmidt, Lutz wrote:
        >>      >      > Dear all,
        >>      >      >
        >>      >      > may I please have reviews for this (semantically) small change. Its purpose is to
        >> reduce the bufferedStream buffer flushes while printing CodeHeap Analytics.
        >>      >      >
        >>      >      > Bug:    https://bugs.openjdk.java.net/browse/JDK-8217250
        >>      >      > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8217250.00/
        >>      >      >
        >>      >      > Thank you!
        >>      >      > Lutz
        >>      >      >
        >>      >      >
        >>      >
        >>      >
        >>