RFR(S): 8200450: Analysis and fix for JDK-8200366 (SIGSEGV in print_names())

[Schmidt, Lutz]

Hi Vladimir, 
sorry for the build warning. I fixed it by using "size_t for local var "end_ix". Webrev was updated in-place.

And, of course, thanks for running the tests!

Regards, Lutz

On 18.04.18, 01:12, "Vladimir Kozlov" <vladimir.kozlov at oracle.com> wrote:

    I got build failure on Windows:
    
    src/hotspot/share/code/codeHeapState.cpp(2098) : warning C4267: 'initializing' : conversion from 
    'size_t' to 'unsigned int', possible loss of data
    
    Testing on other platforms seems fine.
    
    Thanks,
    Vladimir
    
    On 4/17/18 2:15 PM, Vladimir Kozlov wrote:
    > Thank you, Lutz
    > 
    > I agree with this approach with additional safeguarding checks. It has less affects on other code.
    > 
    > I start testing of these changes.
    > 
    > Thanks,
    > Vladimir
    > 
    > On 4/17/18 8:49 AM, Schmidt, Lutz wrote:
    >> Dear all,
    >>
    >> may I please request your comments on this topic.
    >>
    >> I have invested quite some time in testing, reproducing, analyzing, and fixing the effects that 
    >> caused the CodeHeap State Analytics function print_names() to SIGSEGV (very rare, intermittent). 
    >> Please refer to my description in the bug for the details (I did not want to duplicate it here).
    >>
    >> I have prepared an preliminary webrev as a basis for further discussions. The webrev is 
    >> preliminary at least with respect to the debugging/tracing output which is still in there 
    >> intentionally. I thought it might be helpful for you to see how I tested that the changes actually 
    >> hardened the code. A potential push candidate would have all #ifdef JDK8200450_TRACE sections 
    >> removed. All #ifndef JDK8200450_REMEDY sections would be gone as well.
    >>
    >> As workload I ran SPECjvm2008. From a separate process, I hammered sets of
    >>   - ${jcmd} ${testPID} Compiler.CodeHeap_Analytics discard
    >>   - ${jcmd} ${testPID} Compiler.CodeHeap_Analytics aggregate
    >>   - ${jcmd} ${testPID} Compiler.CodeHeap_Analytics MethodNames (50 repetitions)
    >>   - start over
    >> against the JVM. The pace was only limited by system capabilities. I scanned the output for marker 
    >> strings to find handled issues which previously would have caused a SIGSEGV. Platforms tested are 
    >> bsd_x86, linux_x86, linux_ppc, linux_s390. A handled issue was reported less frequently than 1 in 
    >> 10,000. Unhandled issued were not encountered at all.
    >>
    >> In addition, I cleaned the format strings a bit, replacing "%p" by INTPTR_FORMAT.
    >>
    >> Bug:    https://bugs.openjdk.java.net/browse/JDK-8200450
    >> Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8200450.00/
    >>
    >> Thanks for having a look!
    >> Lutz
    >>