RFR(L): 8198691: CodeHeap State Analytics

[Vladimir Kozlov]

I think you should follow what we do with CodeCache::print_summary():

http://hg.openjdk.java.net/jdk/hs/file/74db2b7cec75/src/hotspot/share/code/codeCache.cpp#l1359

First, print into local buffer stringStream and then lock tty when print that buffer.

Thanks,
Vladimir

On 3/20/18 11:29 AM, Schmidt, Lutz wrote:
> Hi Tobias,
> 
> thank you for uncovering this. In CodeCache::report_codemem_full() I oversaw that the tty lock is held at the place I inserted the call to CompileBroker::print_heapinfo().
> 
> That bug triggered some thoughts in my brain, resulting in a question or two:
> 
> Given the complex output of CompileBroker::print_heapinfo(), what would be the OpenJDK approach to tty locking?
> 
> Should I do "micro locking", trying to keep together only small blocks? That's what is implemented now.
> Should I lock tty before each call to a print function (like print_usedSpace, print_freeSpace, ...)?
> 
> Either approach has its advantages, so I'm more or less neutral. What do you all think?
> 
> Depending on what's in favor by the community, I will move the locks accordingly.
> 
> Thanks,
> Lutz
> 
> 
> On 20.03.18, 15:45, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:
> 
>      Hi Lutz,
>      
>      I've already started testing with -Xlog:codecache=Debug and found a problem:
>      
>      The following tests
>      compiler/whitebox/AllocationCodeBlobTest.java
>      compiler/codecache/OverflowCodeCacheTest.java
>      compiler/codecache/stress/ReturnBlobToWrongHeapTest.java
>      compiler/codecache/stress/RandomAllocationTest.java
>      compiler/profiling/spectrapredefineclass_classloaders/Launcher.java
>      compiler/profiling/spectrapredefineclass/Launcher.java
>      
>      fail with
>      #  fatal error: acquiring lock CodeHeapStateAnalytics_lock/6 out of order with lock tty_lock/0 --
>      possible deadlock
>      
>      Let me know if you need more information to reproduce!
>      
>      Thanks,
>      Tobias
>      
>      On 20.03.2018 11:25, Schmidt, Lutz wrote:
>      > Hi Tobias,
>      >
>      > thank you! If you haven't started yet, you may want to wait with testing a moment. I will remove the comments Vladimir and you complained about and update the webrev. It's comments only, but you never know...
>      >
>      > Thanks,
>      > Lutz
>      >
>      > On 20.03.18, 10:46, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:
>      >
>      >     Hi Lutz,
>      >
>      >     very nice work! Thanks for incorporating the requested changes. I think you can remove the commented
>      >     LogStream code.
>      >
>      >     I'll re-run the tests that failed with the last webrev.
>      >
>      >     Best regards,
>      >     Tobias
>      >
>      >     On 19.03.2018 17:00, Schmidt, Lutz wrote:
>      >     > Dear all,
>      >     >
>      >     > this is the next (second) iteration of my CodeHeap State Analytics effort. It reflects all the comments and suggestions I received on my initial RFR (sent out on March 1st). Please read on to learn what was changed and what kept as is.
>      >     >
>      >     > May I please request reviews for
>      >     >
>      >     > Bug:    https://bugs.openjdk.java.net/browse/JDK-8198691
>      >     > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8198691.01/
>      >     >
>      >     > Instead of keeping the long tail of comments and responses, I decided to provide a summary of what happened.
>      >     >  - Most of the new code was moved to new files: share/code/codeHeapState.cpp and share/code/codeHeapState.hpp
>      >     >  - I have added, as requested, an abbreviated version of the "General Description" chapter to codeHeapState.cpp
>      >     >  - In case of SegmentedCodeCache, the iteration is limited to FOR_ALL_ALLOCABLE_HEAPS(). There were issues in aot tests when using FOR_ALL_HEAPS().
>      >     >  - All references to the RFE id should be gone.
>      >     >  - In share/runtime/java.cpp, the call to CompileBroker::print_heapinfo() now is close to "PrintCodeCache" for both, product and nonproduct cases.
>      >     >  - The edited/updated documentation is available as an attachment to the bug (in PDF format).
>      >     >  - I added code to share/code/codeCache.cpp (report_codemem_full()) to print the CodeHeap state for the first occurrence of the "full" condition.
>      >     >  - The code style "hickups", noted by Tobias Hartmann, are gone.
>      >     >  - The compile time warnings and errors are resolved.
>      >     >
>      >     > -XX:+PrintCodeHeapState vs. -Xlog:codecache=Trace
>      >     > I clearly understand and support the intention to get rid of the Print* command line arguments. Therefore, the PrintCodeHeapState command line argument is gone. You can request the CodeHeap state analytics with the -Xlog:codecache=Trace (vm shutdown) or -Xlog:codecache=Debug (CodeCache full and vm shutdown) switches. The output is directed to tty, not to the log stream.
>      >     >
>      >     > The reason for not using the log stream is simple: UL prefixes every line with a timestamp and the trace tags. Unfortunately, that messes up my formatting big time. The jcmd output, on the other hand, will not have the UL prefixes. I would have to distinguish between UL and jcmd output when formatting. In addition, I do not see a benefit from adding the same UL prefix to thousands of lines.
>      >     >
>      >     > Comments are very welcome!
>      >     >
>      >     > Best Regards,
>      >     > Lutz
>      >     >
>      >     >
>      >     >
>      >     >
>      >
>      >
>      
>