RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (serviceability)

[Mikael Vidstedt]

> On May 6, 2020, at 3:19 PM, serguei.spitsyn at oracle.com wrote:
> 
> 
> 
> On 5/6/20 11:12, serguei.spitsyn at oracle.com <mailto:serguei.spitsyn at oracle.com> wrote:
>> On 5/6/20 10:58, coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com> wrote:
>>> 
>>> 
>>> On 5/6/20 1:04 PM, serguei.spitsyn at oracle.com <mailto:serguei.spitsyn at oracle.com> wrote:
>>>> On 5/6/20 03:40, coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> On 5/6/20 2:09 AM, serguei.spitsyn at oracle.com <mailto:serguei.spitsyn at oracle.com> wrote:
>>>>>> On 5/5/20 17:04, Mikael Vidstedt wrote:
>>>>>>>> On May 5, 2020, at 4:48 PM, serguei.spitsyn at oracle.com <mailto:serguei.spitsyn at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Hi Mikael,
>>>>>>>> 
>>>>>>>> The fixes in webrev look good to me.
>>>>>>>> 
>>>>>>>> I've just noticed a couple of more serviceability related things can be missed.
>>>>>>>> (Not sure if they are included into different chunk of fixes.)
>>>>>>>> 
>>>>>>>> One is libjvm_db.so which is for Solaris Pstack support:
>>>>>>>>   make/hotspot/lib/CompileDtraceLibraries.gmk:    # Note that libjvm_db.c has tests for COMPILER2, but this was never set by
>>>>>>>>   make/hotspot/lib/CompileDtraceLibraries.gmk: LIBJVM_DB_OUTPUTDIR := $(JVM_VARIANT_OUTPUTDIR)/libjvm_db
>>>>>>>>   make/hotspot/lib/CompileDtraceLibraries.gmk:        NAME := jvm_db, \
>>>>>>>>   make/hotspot/lib/CompileDtraceLibraries.gmk:        SRC := $(TOPDIR)/src/java.base/solaris/native/libjvm_db, \
>>>>>>>> 
>>>>>>>> Another is DTrace support which also includes jhelper.d (support for DTrace jstack action which is for Solaris only):
>>>>>>>>   make/hotspot/gensrc/GensrcDtrace.gmk
>>>>>>>>   make/hotspot/lib/JvmDtraceObjects.gmk
>>>>>>>> It also impacts some other make files.
>>>>>>> I believe you’ll find that these changes were included in the build system patch:
>>>>>>> 
>>>>>>> https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027342.html <https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027342.html>
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/build/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/build/open/webrev/>
>>>>>>> 
>>>>>>> Let me know if I missed something.
>>>>>> 
>>>>>> The file make/hotspot/src/native/dtrace/generateJvmOffsets.cpp is for Solaris only, and so, can be removed.
>>>>>> It is for libjvm_db.so (provider for Solaris Pstack) and jhelper.d (provider for Solaris DTrace jstack action).
>>>>>> The jstack action (prints mixed java+native stack traces) was never implemented other than for Solaris.
>>>>> 
>>>>> I wonder if this can be used to implement the same thing on linux and if we can keep this?  Thoughts?
>>>> 
>>>> I was also thinking about it. And DTrace kind of exists on Mac OS as well.
>>>> Yes, it can be used. But It will require the jstack action implementation and the jhelper use on the DTrace side.
>>> 
>>>> The same is true for the libjvm_db.so. It could be used in the Linux Pstack utility to print mixed stack traces.
>>>> (I see some pstack projects like this: https://github.com/peadar/pstack <https://github.com/peadar/pstack> )
>>> Yes, I was thinking specifically of the pstack utility and not DTrace, just to get Java frames in ptrace.  Could libjvm_db.so be used for that?
>> 
>> Yes, it can be.
>> The work needs to be done on the Linux side to get use of the libjvm_db.so.
>> We worked with the Solaris team in the past to make the Pstack to print java frames (including virtual ones).
>> The libjvm_db API came out from discussions with them.
>> The interface is pretty simple:
>> The Pstack does one initialization call and then in a loop requests the java frame strings from the register context (pc, sp and fp).
>> Each time the libjvm_db returns corrected register state to help with the stack walking steps.
>> It is kind of assisted stack walking.
> 
> We had a local chat with Mikael and Coleen on this.
> The conclusion is that we’ll remove it for now and restore it later if needed.
> This folder has to be also removed with this:
>   src/java.base/solaris/native/libjvm_db

Thank you Serguei & Coleen for the discussion! As we concluded the code will still be there in the history in case we need inspiration, leaving it in (without actually being used) will just lead to inevitable bit-rot.

Cheers,
Mikael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20200506/e21ad059/attachment.htm>