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

[Thomas Stüfe]

Okay, lets do it in a cleanup change.

..Thomas

On Wed, Apr 18, 2018 at 11:07 AM, Schmidt, Lutz <lutz.schmidt at sap.com> wrote:
> Hi Thomas,
>
> good observation! I "stole" the code from SAP JVM, where it is generally available in the os namespace.
>
> While I agree that is_pointer_readable() would be generally useful, I do not want to further blow up this change. I would rather do that separately.
>
> Regards, Lutz
>
> On 18.04.18, 06:20, "Thomas Stüfe" <thomas.stuefe at gmail.com> wrote:
>
>     Hi Lutz,
>
>     not a review, just a remark. is_readable_pointer is useful as a
>     general function, could you move it to the os namespace?
>
>     If you do this, it may make sense to make it possible to specify the
>     default-before-stub-initialization like this:
>
>     bool os::is_readable_pointer(void* p, bool defaultvalue = true);
>
>     And also maybe consolidate it with the variant we use in the AIX port
>     (see MiscUtils::is_readable_pointer(const void* p) in
>     src/hotspot/os/aix/misc_aix.hpp/cpp)? (as in, throw out the AIX
>     version and replace its calls with the new os::is_readable_pointer) ?
>
>     Thanks a lot!
>
>     ..Thomas
>
>     On Tue, Apr 17, 2018 at 5:49 PM, Schmidt, Lutz <lutz.schmidt at sap.com> 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
>     >
>     >
>
>