[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: RFR(s):8252101 Add specification of expected behavior of combining "all" and "live" options of j
From:       "Hohensee, Paul" <hohensee () amazon ! com>
Date:       2020-08-24 18:30:13
Message-ID: 9D34568A-AEF4-4DA3-85D1-6362B5EF36F0 () amazon ! com
[Download RAW message or body]

The CSR has been approved. I'll push for you as soon as the openjdk servers come back.

Thanks,
Paul

On 8/23/20, 8:30 PM, "linzang(臧琳)" <linzang@tencent.com> wrote:

    Hi Paul, Serguei and Dan,

        Thanks for help review it.  The CSR is in "Finalized" status, I will
    wait for it to be approved and then may ask your help to push it.

    Cheers,

    Lin


    On 22/08/2020 08:46, serguei.spitsyn@oracle.com wrote:
    > Hi Lin,
    >
    > LGTM++
    >
    > Thanks,
    > Serguei
    >
    >
    > On 8/21/20 14:01, Daniel D. Daugherty wrote:
    >> On 8/20/20 7:42 PM, linzang(臧琳) wrote:
    >>> After discuss with paul, it is not a good idea to combine two fix
    >>> together in one webrev. I will handle them separately
    >>> Please help review the updated one. Thanks!
    >>>     Webrev: http://cr.openjdk.java.net/~lzang/8252101/webrev.01/
    >> src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java
    >>     No comments.
    >>
    >> Thumbs up.
    >>
    >> Dan
    >>
    >>
    >>>              CSR: https://bugs.openjdk.java.net/browse/JDK-8252102
    >>>              Bug: https://bugs.openjdk.java.net/browse/JDK-8252101
    >>>   BRs,
    >>> Lin
    >>>
    >>> On 2020/8/21, 12:17 AM, "linzang(臧琳)" <linzang@tencent.com> wrote:
    >>>
    >>>      Dear All,
    >>>              May I ask your help to review this change:
    >>>              Webrev:
    >>> http://cr.openjdk.java.net/~lzang/8252101/webrev.00/
    >>>              CSR: https://bugs.openjdk.java.net/browse/JDK-8252102
    >>>              Bug: https://bugs.openjdk.java.net/browse/JDK-8252101
    >>>
    >>>              This change adds the description of expected behavior
    >>> for jmap -hiso/-dump to use "all" and "live" at the same time.
    >>>              With Paul's help, It also includes code refine of the
    >>> dump() function in Jmap.java. which is based on Paul's change
    >>> http://cr.openjdk.java.net/~phh/8251835/webrev.00/
    >>>
    >>>      BRs,
    >>>      Lin
    >>>
    >>>      On 2020/8/20, 8:18 PM, "linzang(臧琳)" <linzang@tencent.com> wrote:
    >>>
    >>>          Thanks Paul!
    >>>              I have filed CSR and Bug:
    >>>              CSR: https://bugs.openjdk.java.net/browse/JDK-8252102
    >>>              Bug: https://bugs.openjdk.java.net/browse/JDK-8252101
    >>>
    >>>              Patch is under testing,  will create  RFR thread when it
    >>> is ready.
    >>>          Thanks!
    >>>
    >>>          Cheers,
    >>>          Lin
    >>>
    >>>          On 20/08/2020 04:18, Hohensee, Paul wrote:
    >>>          > I prioritize compatibility, so would go with option 2.
    >>>          >
    >>>          > Thanks,
    >>>          > Paul
    >>>          >
    >>>          > On 8/18/20, 11:17 PM, "serviceability-dev on behalf of
    >>> linzang(臧琳)" <serviceability-dev-retn@openjdk.java.net on behalf of
    >>> linzang@tencent.com> wrote:
    >>>          >
    >>>          >     Dear All,
    >>>          >             May I get some suggestions?  so that I can
    >>> work out a patch
    >>>          >     base on that.
    >>>          >             Or may be it should not be treated as an issue?
    >>>          >     BRs,
    >>>          >     Lin
    >>>          >
    >>>          >     On 17/08/2020 17:17, linzang(臧琳) wrote:
    >>>          >     >  Dear all,
    >>>          >     >           we found the jmap's histo/dump command
    >>> could accept "live" and "all" options together, and the specification
    >>> does not describe what is the expected behavior of it.
    >>>          >     >           I have tried that when these two options
    >>> used together, the "live" takes effect, no matter what sequences are
    >>> they in commandline.
    >>>          >     >           IMO, it is a little confused to use "live"
    >>> and "all" together, and if it is allowed, the specification may need
    >>> to be updated to state the behavior clearly.
    >>>          >     >           Therefore may I ask your suggestion on
    >>> which option of the following is prefered:
    >>>          >     >           (option 1.)  disallow using these two
    >>> options together, I think this is more clear, but I am not sure
    >>> whether there is backward compatibility risk.
    >>>          >     >           (option 2.)  allow the combination use of
    >>> "live" and "all", and update the specification to clearly describe
    >>> the behavior that "live" takes effect in this case.
    >>>          >     >           What do you think?
    >>>          >     >
    >>>          >     > Thanks,
    >>>          >     > Lin
    >>>          >     >
    >>>          >     >
    >>>          >     >
    >>>          >
    >>>          >
    >>>          >
    >>>
    >>>
    >>>
    >



[prev in list] [next in list] [prev in thread] [next in thread]