RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent.

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Wed Feb 17 19:34:28 UTC 2016


On 2/17/16 03:42, Yasumasa Suenaga wrote:
> Hi all,
>
> Jaroslav found that a patch for JDK-8147388 cannot build on Windows.
> So I fix it in new webrev:
>
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.05/
>
> jtreg test for this feature is passed on Windows i586 and Fedora23 
> x86_64.
> Could you review it again?

It looks good.

Thanks,
Serguei

>
>
> Thanks,
>
> Yasumasa
>
>
> On 2016/01/24 2:37, Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> Looks good for me!
>>
>> -Dmitry
>>
>> On 2016-01-23 17:18, Yasumasa Suenaga wrote:
>>> Dmitry,
>>>
>>> Thank you for your explanation.
>>> I've added length check with 4096 bytes in new webrev:
>>>
>>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.04/
>>>
>>> PATH_MAX is not defined Visual C++ 2015.
>>> So I do not use this macro.
>>>
>>>
>>> Could you review again?
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/01/22 18:41, Dmitry Samersoff wrote:
>>>> Yasumasa,
>>>>
>>>> It's dangerous to allow arbitrary length string to be passed to 
>>>> running
>>>> process. We should limit it to some reasonable value.
>>>>
>>>> It is much easier to increase the limit if necessary than debug random
>>>> allocation failures caused by too long string.
>>>>
>>>> e.g.
>>>>
>>>> Corrupted script (or admin mistake) send a 1Gb of garbage to VM as an
>>>> options. VM successfully allocate memory for options within DCMD 
>>>> but OOM
>>>> later somewhere in C2 or JVMTI.
>>>>
>>>> How long it takes to find real cause of the problem?
>>>>
>>>> -Dmitry
>>>>
>>>> On 2016-01-22 11:56, Yasumasa Suenaga wrote:
>>>>> Dmitry,
>>>>>
>>>>> Can we limit the length of argument?
>>>>> I guess that we can pass more length when we use -agentlib,
>>>>> -javaagent, etc.
>>>>> (I do not know about commandline length.)
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>> 2016/01/22 17:45 "Dmitry Samersoff" <dmitry.samersoff at oracle.com
>>>>> <mailto:dmitry.samersoff at oracle.com>>:
>>>>>
>>>>>       Yasumasa,
>>>>>
>>>>>       I would prefer to check that opt_len is less than PATH_MAX
>>>>> *before* any
>>>>>       attempt to allocate memory to avoid any possible 
>>>>> attack/missuses.
>>>>>
>>>>>       I.e.:
>>>>>
>>>>>       int opt_len = strlen(_libpath.value()) + 
>>>>> strlen(_option.value())
>>>>> + 2;
>>>>>       if (opt_len > PATH_MAX) {
>>>>>          output()->print_cr("JVMTI agent attach failed: "
>>>>>         "Options is too long.");
>>>>>          return;
>>>>>       }
>>>>>
>>>>>       char *opt = (char *)os::malloc(opt_len, mtInternal);
>>>>>       if (opt == NULL) {
>>>>>         output()->print_cr("JVMTI agent attach failed: "
>>>>>                            "Could not allocate %d bytes for 
>>>>> argument.",
>>>>>                                     opt_len);
>>>>>       }
>>>>>
>>>>>
>>>>>       -Dmitry
>>>>>
>>>>>
>>>>>       On 2016-01-22 06:21, Yasumasa Suenaga wrote:
>>>>>       > Hi,
>>>>>       >
>>>>>       > I think that we can check malloc error as below:
>>>>>       > --------------
>>>>>       >       int opt_len = strlen(_libpath.value()) +
>>>>>       strlen(_option.value()) + 2;
>>>>>       >       char *opt = (char *)os::malloc(opt_len, mtInternal);
>>>>>       >       if (opt == NULL) {
>>>>>       >         // 4096 comes from PATH_MAX at Linux.
>>>>>       >         if (opt_len > 4096) {
>>>>>       >           output()->print_cr("JVMTI agent attach failed: "
>>>>>       >                              "Could not allocate %d bytes for
>>>>>       argument.",
>>>>>       >                              opt_len);
>>>>>       >         } else {
>>>>>       >           // VM might not work because memory exhausted.
>>>>>       >           vm_exit_out_of_memory(opt_len, OOM_MALLOC_ERROR,
>>>>>       > "JVMTIAgentLoadDCmd::execute");
>>>>>       >         }
>>>>>       >       }
>>>>>       > --------------
>>>>>       >
>>>>>       > If you think that this code should NOT be available in 
>>>>> dcmd, I
>>>>>       will remove
>>>>>       > vm_exit_out_of_memory() from it.
>>>>>       >
>>>>>       >
>>>>>       > Thanks,
>>>>>       >
>>>>>       > Yasumasa
>>>>>       >
>>>>>       >
>>>>>       > 2016-01-20 18:06 GMT+09:00 Yasumasa Suenaga 
>>>>> <yasuenag at gmail.com
>>>>>       <mailto:yasuenag at gmail.com>
>>>>>       > <mailto:yasuenag at gmail.com <mailto:yasuenag at gmail.com>>>:
>>>>>       >
>>>>>       >     I agree to Dmitry.
>>>>>       >
>>>>>       >     Most case of malloc error, native memory is exhausted.
>>>>>       >     Thus I think process (or system) is illegal state. It 
>>>>> should
>>>>>       be shut
>>>>>       >     down.
>>>>>       >     If do not so, malloc failure might be occurred another 
>>>>> point.
>>>>>       >
>>>>>       >     However, I think that it is very difficult to set the
>>>>> threshold.
>>>>>       >     If it can be clear, I will make a new webrev.
>>>>>       >
>>>>>       >     Thanks,
>>>>>       >
>>>>>       >     Yasumasa
>>>>>       >
>>>>>       >     2016/01/20 17:03 "Dmitry Samersoff"
>>>>>       <dmitry.samersoff at oracle.com 
>>>>> <mailto:dmitry.samersoff at oracle.com>
>>>>>       >     <mailto:dmitry.samersoff at oracle.com
>>>>>       <mailto:dmitry.samersoff at oracle.com>>>:
>>>>>       >
>>>>>       >         David,
>>>>>       >
>>>>>       >         PS:
>>>>>       >          It might be a good to check opt_len for some large
>>>>> enough
>>>>>       value
>>>>>       >         (like
>>>>>       >         2048) before allocation attempt and send back a 
>>>>> message.
>>>>>       >
>>>>>       >         -Dmitry
>>>>>       >
>>>>>       >         On 2016-01-20 08:03, David Holmes wrote:
>>>>>       >         > On 20/01/2016 9:13 AM, Yasumasa Suenaga wrote:
>>>>>       >         >> Hi David,
>>>>>       >         >>
>>>>>       >         >> ShouldNotReachHere( ) is called at NMTDcmd:
>>>>>       >         >>
>>>>>       >
>>>>>
>>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/8fcd5cba7938/src/share/vm/services/nmtDCmd.cpp#l156 
>>>>>
>>>>>
>>>>>       >         >>
>>>>>       >         >
>>>>>       >         > Sure but that is more of a debugging check - we
>>>>> never expect
>>>>>       >         to reach
>>>>>       >         > that code.
>>>>>       >         >
>>>>>       >         > Unfortunately I do see some other implicit aborts
>>>>> due to
>>>>>       >         allocation
>>>>>       >         > failures, but I have to say this seems very 
>>>>> wrong to
>>>>> me.
>>>>>       >         >
>>>>>       >         > David
>>>>>       >         > -----
>>>>>       >         >
>>>>>       >         >> If target VM is aborted, caller (e.g. jcmd) cannot
>>>>> receive
>>>>>       >         response. I
>>>>>       >         >> think that the caller show Exception.
>>>>>       >         >>
>>>>>       >         >> Thanks,
>>>>>       >         >>
>>>>>       >         >> Yasumasa
>>>>>       >         >>
>>>>>       >         >> 2016/01/20 7:37 "David Holmes"
>>>>> <david.holmes at oracle.com
>>>>>       <mailto:david.holmes at oracle.com>
>>>>>       >         <mailto:david.holmes at oracle.com
>>>>>       <mailto:david.holmes at oracle.com>>
>>>>>       >         >> <mailto:david.holmes at oracle.com
>>>>>       <mailto:david.holmes at oracle.com>
>>>>>       >         <mailto:david.holmes at oracle.com
>>>>>       <mailto:david.holmes at oracle.com>>>>:
>>>>>       >         >>
>>>>>       >         >>     On 19/01/2016 11:19 PM, Yasumasa Suenaga 
>>>>> wrote:
>>>>>       >         >>
>>>>>       >         >>         Hi,
>>>>>       >         >>
>>>>>       >         >>         I uploaded a new webrev:
>>>>>       >         >>
>>>>>       >
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.03/
>>>>>       >         >>
>>>>>       >         >>         It is malloc/free version.
>>>>>       >         >>         If NULL returns from malloc(), it calls
>>>>>       >         vm_exit_out_of_memory().
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>     That seems rather extreme - do other dcmd 
>>>>> failures
>>>>>       abort
>>>>>       >         the VM? I
>>>>>       >         >>     would have expected some kind of error
>>>>> propagation back
>>>>>       >         to the
>>>>>       >         >> caller.
>>>>>       >         >>
>>>>>       >         >>     Thanks,
>>>>>       >         >>     David
>>>>>       >         >>
>>>>>       >         >>         All test about this changes work fine.
>>>>>       >         >>         Please review.
>>>>>       >         >>
>>>>>       >         >>         Thanks,
>>>>>       >         >>
>>>>>       >         >>         Yasumasa
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>         On 2016/01/19 22:07, Dmitry Samersoff 
>>>>> wrote:
>>>>>       >         >>
>>>>>       >         >>             David,
>>>>>       >         >>
>>>>>       >         >>                 Anytime we start to use a language
>>>>> feature
>>>>>       >         for the first
>>>>>       >         >>                 time we need
>>>>>       >         >>                 to be extra diligent to make sure
>>>>> there are
>>>>>       >         no unintended
>>>>>       >         >>                 side-effects and that all our
>>>>> supported
>>>>>       >         compilers (and
>>>>>       >         >>                 probably a few
>>>>>       >         >>                 others used in the community) do
>>>>> the right
>>>>>       >         thing. A bit
>>>>>       >         >>                 of googling
>>>>>       >         >>                 seems to indicate that variable 
>>>>> length
>>>>>       arrays
>>>>>       >         are part
>>>>>       >         >>                 of C99 but are
>>>>>       >         >>                 not allowed in C++ - though gcc 
>>>>> has an
>>>>>       >         extension that
>>>>>       >         >>                 does allow
>>>>>       >         >>                 them.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>             I hear your concern.
>>>>>       >         >>
>>>>>       >         >>             Moreover I revisit my advice and think
>>>>> it's
>>>>>       not a
>>>>>       >         good idea
>>>>>       >         >>             to do a
>>>>>       >         >>             stack allocation based on 
>>>>> unverified user
>>>>>       input.
>>>>>       >         >>
>>>>>       >         >>             Yasumasa, sorry for leading in wrong
>>>>> direction.
>>>>>       >         Lets use
>>>>>       >         >>             malloc/free in
>>>>>       >         >>             this case.
>>>>>       >         >>
>>>>>       >         >>             Nevertheless, I would like to start
>>>>> broader
>>>>>       >         evaluation of
>>>>>       >         >>             possible use
>>>>>       >         >>             on-stack allocation (either alloca or
>>>>> VLA) -
>>>>>       >         hotspot may
>>>>>       >         >>             benefit of it
>>>>>       >         >>             in many places.
>>>>>       >         >>
>>>>>       >         >>             -Dmitry
>>>>>       >         >>
>>>>>       >         >>             On 2016-01-19 02:06, David Holmes 
>>>>> wrote:
>>>>>       >         >>
>>>>>       >         >>                 On 19/01/2016 7:26 AM, Dmitry
>>>>> Samersoff
>>>>>       wrote:
>>>>>       >         >>
>>>>>       >         >>                     David,
>>>>>       >         >>
>>>>>       >         >>                     On 2016-01-18 23:47, David 
>>>>> Holmes
>>>>>       wrote:
>>>>>       >         >>
>>>>>       >         >>                         On 18/01/2016 11:20 PM, 
>>>>> Dmitry
>>>>>       >         Samersoff wrote:
>>>>>       >         >>
>>>>>       >         >> Yasumasa,
>>>>>       >         >>
>>>>>       > >>                                 Can we use VLA
>>>>> (Variable
>>>>>       >         Length Arrays) ?
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >> Apple LLVM version 6.1.0
>>>>>       >         (clang-602.0.53)
>>>>>       >         >> (based on LLVM
>>>>>       >         >> 3.6.0svn) Target:
>>>>>       >         x86_64-apple-darwin14.5.0
>>>>>       >         >> Thread model:
>>>>>       >         >> posix
>>>>>       >         >>
>>>>>       >         >> Compiles it just fine.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>                         Are we using variable
>>>>> length arrays
>>>>>       >         anywhere
>>>>>       >         >>                         else in the VM yet?
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>                     Probably not.
>>>>>       >         >>
>>>>>       >         >>                     But personally, I see no 
>>>>> reason to
>>>>>       don't
>>>>>       >         use it for
>>>>>       >         >>                     simple cases
>>>>>       >         >>                     like this one.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>                 Anytime we start to use a language
>>>>> feature
>>>>>       >         for the first
>>>>>       >         >>                 time we need
>>>>>       >         >>                 to be extra diligent to make sure
>>>>> there are
>>>>>       >         no unintended
>>>>>       >         >>                 side-effects and that all our
>>>>> supported
>>>>>       >         compilers (and
>>>>>       >         >>                 probably a few
>>>>>       >         >>                 others used in the community) do
>>>>> the right
>>>>>       >         thing. A bit
>>>>>       >         >>                 of googling
>>>>>       >         >>                 seems to indicate that variable 
>>>>> length
>>>>>       arrays
>>>>>       >         are part
>>>>>       >         >>                 of C99 but are
>>>>>       >         >>                 not allowed in C++ - though gcc 
>>>>> has an
>>>>>       >         extension that
>>>>>       >         >>                 does allow
>>>>>       >         >>                 them.
>>>>>       >         >>
>>>>>       >         >>                 This reports they are not 
>>>>> available in
>>>>>       Visual
>>>>>       >         Studio C++:
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > https://msdn.microsoft.com/en-us/library/zb1574zs.aspx
>>>>>       >         >>
>>>>>       >         >>                 David -----
>>>>>       >         >>
>>>>>       >         >>                         What are the 
>>>>> implications for
>>>>>       >         allocation and in
>>>>>       >         >> particular
>>>>>       >         >> allocation failure?
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>                     This allocation just 
>>>>> reserves some
>>>>>       space
>>>>>       >         on the
>>>>>       >         >>                     stack[1], so it
>>>>>       >         >>                     can cause stack overflow if we
>>>>>       attempt to
>>>>>       >         allocate
>>>>>       >         >>                     two much bytes.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>                     1. Listing fragment (extra
>>>>> labels are
>>>>>       >         removed)
>>>>>       >         >>
>>>>>       >         >> 3                    .Ltext0: 5
>>>>>       >         >> .LC0:
>>>>>       >         >>
>>>>>       >         >> 14:test.cxx      **** void
>>>>>       testme(int n) {
>>>>>       >         >> 15:test.cxx      ****
>>>>>       >         >>                     char m[n]; 25 0000 4863FF
>>>>>       >         movslq
>>>>>       >         >>                     %edi, %rdi 28 0003
>>>>>       >         >> 55                    pushq
>>>>> %rbp 37
>>>>>       >         0004 BE000000
>>>>>       >         >>                     movl $.LC0, %esi 41 0009
>>>>> 4883C70F
>>>>>       >         >>                     addq $15,
>>>>>       >         >>                     %rdi 46 000d
>>>>> 31C0                  xorl
>>>>>       >           %eax,
>>>>>       >         >>                     %eax 50 000f
>>>>>       >         >> 4883E7F0              andq
>>>>> $-16,
>>>>>       %rdi
>>>>>       >         54 0013
>>>>>       >         >> 4889E5
>>>>>       >         >>                     movq %rsp, %rbp 59 0016 4829FC
>>>>>       >         >>                     subq %rdi,
>>>>>       >         >>                     %rsp 64 0019
>>>>> BF010000              movl
>>>>>       >           $1, %edi
>>>>>       >         >>                     65 001e 4889E2
>>>>>       >         >>                     movq %rsp, %rdx 66 0021
>>>>> E8000000
>>>>>       >                 call
>>>>>       >         >> __printf_chk 16:test.cxx      ****
>>>>>       >          printf("%s",
>>>>>       >         >>                     m); 17:test.cxx
>>>>>       >         >>                     **** }
>>>>>       >         >>
>>>>>       >         >>                     -Dmitry
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>                         David -----
>>>>>       >         >>
>>>>>       >         >> -Dmitry
>>>>>       >         >>
>>>>>       >         >>                             On 2016-01-18 16:09,
>>>>> Yasumasa
>>>>>       >         Suenaga wrote:
>>>>>       >         >>
>>>>>       > >>                                 Hi Dmitry,
>>>>>       >         >>
>>>>>       > >>                                     1. It might be
>>>>>       better to
>>>>>       >         have one
>>>>>       > >>                                     jcmd to run both
>>>>>       java and
>>>>>       > >>                                     native java
>>>>> agent. If
>>>>>       >         agent library
>>>>>       > >>                                     name ends with
>>>>> ".jar"
>>>>>       > >>                                     we can assume
>>>>> it's java
>>>>>       >         agent.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                 Okay, I'll try it.
>>>>>       >         >>
>>>>>       > >>                                     if
>>>>> (_libpath.value() ==
>>>>>       >         NULL) {
>>>>>       > >>                                     error ... }
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                 I will add it.
>>>>> However, I
>>>>>       >         note you that
>>>>>       > >>                                 _libpath is given
>>>>>       > >>                                 mandatory flag.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-January/018661.html 
>>>>>
>>>>>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>             char options[option_len];
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                 Can we use VLA
>>>>> (Variable
>>>>>       >         Length Arrays)
>>>>>       > >>                                 ? I'm worried that
>>>>>       > >>                                 several C++
>>>>> compiler cannot
>>>>>       >         compile this
>>>>>       > >>                                 code.
>>>>>       >         >>
>>>>>       >         >> http://clang.llvm.org/compatibility.html#vla
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                 Thanks,
>>>>>       >         >>
>>>>>       > >>                                 Yasumasa
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                 On 2016/01/18
>>>>> 19:38, Dmitry
>>>>>       >         Samersoff
>>>>>       >         >> wrote:
>>>>>       >         >>
>>>>>       > >>                                     Yasumasa,
>>>>>       >         >>
>>>>>       > >>                                     1. It might be
>>>>>       better to
>>>>>       >         have one
>>>>>       > >>                                     jcmd to run both
>>>>>       java and
>>>>>       > >>                                     native java
>>>>> agent. If
>>>>>       >         agent library
>>>>>       > >>                                     name ends with
>>>>> ".jar"
>>>>>       > >>                                     we can assume
>>>>> it's java
>>>>>       >         agent.
>>>>>       >         >>
>>>>>       > >>                                     2. Please get
>>>>> rid of
>>>>>       >         malloc/free and
>>>>>       > >>                                     check
>>>>> _libpath.value()
>>>>>       > >>                                     for NULL at ll.
>>>>> 295 and
>>>>>       >         below.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                     if
>>>>> (_libpath.value() ==
>>>>>       >         NULL) {
>>>>>       > >>                                     error ... }
>>>>>       >         >>
>>>>>       > >>                                     if
>>>>> (_option.value() ==
>>>>>       >         NULL) {
>>>>>       >         >>
>>>>>       >         >> JvmtiExport::load_agent_library("instrument",
>>>>>       > >>                                     "false",
>>>>>       > >> _libpath.value(),
>>>>>       output());
>>>>>       >         >> return; }
>>>>>       >         >>
>>>>>       > >>                                     size_t
>>>>> option_len = \
>>>>>       >         >>
>>>>>        strlen(_libpath.value()) +
>>>>>       >         >>
>>>>>        strlen(_option.value()) + 1;
>>>>>       >         >>
>>>>>       > >>                                     char
>>>>>       options[option_len];
>>>>>       >         >>
>>>>>       > >>                                     ....
>>>>>       >         >>
>>>>>       > >>                                     -Dmitry
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                     On 2016-01-15
>>>>>       16:33, Yasumasa
>>>>>       > >>                                     Suenaga wrote:
>>>>>       >         >>
>>>>>       > >>                                         Hi,
>>>>>       >         >>
>>>>>       > >>                                         I added
>>>>> permissions
>>>>>       >         and tests in
>>>>>       > >>                                         new webrev:
>>>>>       >         >>
>>>>>       >         >>
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.01/
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>             Two tests (LoadAgentDcmdTest,
>>>>>       >         LoadJavaAgentDcmdTest) work
>>>>>       >         >> fine.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                         Thanks,
>>>>>       >         >>
>>>>>       > >>                                         Yasumasa
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >>                                         On 2016/01/15
>>>>>       17:20,
>>>>>       >         Staffan
>>>>>       > >>                                         Larsen wrote:
>>>>>       >         >>
>>>>>       > >>                                             This is
>>>>> a good
>>>>>       >         improvement
>>>>>       > >> overall.
>>>>>       >         >>
>>>>>       > >>                                             The new
>>>>>       >         diagnostic commands
>>>>>       > >>                                             need to
>>>>>       have proper
>>>>>       >         >>
>>>>> permissions
>>>>>       set:
>>>>>       >         >>
>>>>>       > >> static
>>>>> const
>>>>>       >         JavaPermission
>>>>>       >         >>
>>>>> permission() {
>>>>>       >         >>
>>>>>        JavaPermission p =
>>>>>       >         >>
>>>>>       >         >> {"java.lang.management.ManagementPermission",
>>>>>       > >> “control",
>>>>>       NULL};
>>>>>       >         return p; }
>>>>>       >         >>
>>>>>       > >>                                             And as
>>>>> David
>>>>>       >         said: tests! See
>>>>>       >         >>
>>>>>       >         >> hotspot/test/serviceability/dcmd/jvmti.
>>>>>       >         >>
>>>>>       > >> Thanks,
>>>>>       /Staffan
>>>>>       >         >>
>>>>>       > >> On
>>>>> 14 jan.
>>>>>       >         2016, at
>>>>>       > >> 15:00,
>>>>>       >         Yasumasa Suenaga
>>>>>       >         >>
>>>>>       >          <yasuenag at gmail.com <mailto:yasuenag at gmail.com>
>>>>>       <mailto:yasuenag at gmail.com <mailto:yasuenag at gmail.com>>
>>>>>       >         >>
>>>>>       >         >> <mailto:yasuenag at gmail.com 
>>>>> <mailto:yasuenag at gmail.com>
>>>>>       <mailto:yasuenag at gmail.com <mailto:yasuenag at gmail.com>>>>
>>>>>       > >> wrote:
>>>>>       >         >>
>>>>>       > >> Hi
>>>>> all,
>>>>>       >         >>
>>>>>       > >> We
>>>>> can use
>>>>>       >         Attach API to
>>>>>       > >> attach
>>>>>       JVMTI
>>>>>       >         agent to
>>>>>       >         >> live
>>>>>       >         >>
>>>>> process.
>>>>>       >         However, we
>>>>>       >         >>
>>>>> have to
>>>>>       write
>>>>>       >         Java code
>>>>>       > >> for
>>>>> it.
>>>>>       >         >>
>>>>>       > >> If
>>>>> we can
>>>>>       >         attach JVMTI
>>>>>       > >> agents
>>>>>       >         through jcmd,
>>>>>       >         >> it is
>>>>>       > >> very
>>>>>       useful.
>>>>>       >         So I want
>>>>>       > >> to
>>>>> add two
>>>>>       >         new diagnostic
>>>>>       >         >>
>>>>> commands:
>>>>>       >         >>
>>>>>       > >>                                                 *
>>>>>       >         JVMTI.agent_load: Load
>>>>>       > >> JVMTI
>>>>>       native
>>>>>       >         agent. *
>>>>>       >         >>
>>>>>       >          JVMTI.javaagent_load:
>>>>>       >         >>
>>>>> Load JVMTI
>>>>>       >         java agent.
>>>>>       >         >>
>>>>>       > >>                                                 I
>>>>> maintain
>>>>>       >         two JVMTI
>>>>>       >         >>
>>>>> agents -
>>>>>       >         HeapStats [1]
>>>>>       >         >> and
>>>>>       >         >>
>>>>>        JLivePatcher
>>>>>       >         [2]. [1] is
>>>>>       > >> native
>>>>>       agent,
>>>>>       >         [2] is java
>>>>>       >         >>
>>>>> agent. They
>>>>>       >         provide a
>>>>>       >         >>
>>>>> program for
>>>>>       >         attaching to
>>>>>       > >> live
>>>>>       >         >>
>>>>> process.
>>>>>       >         >>
>>>>>       > >>                                                 I
>>>>> guess
>>>>>       that
>>>>>       >         various
>>>>>       > >> JVMTI
>>>>>       agents
>>>>>       >         provide own
>>>>>       > >> attach
>>>>>       >         >>
>>>>> mechanism
>>>>>       >         like them. I
>>>>>       > >> think
>>>>>       that we
>>>>>       >         should
>>>>>       >         >> provide
>>>>>       >         >>
>>>>> general way
>>>>>       >         to attach.
>>>>>       >         >>
>>>>>       > >> I've
>>>>>       uploaded
>>>>>       >         webrev.
>>>>>       >         >>
>>>>> Could you
>>>>>       >         review it?
>>>>>       >         >>
>>>>>       >         >>
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.00/
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>             I'm jdk9 committer, however I cannot
>>>>> access
>>>>>       JPRT.
>>>>>       >         >>
>>>>>       > >> So
>>>>> I need a
>>>>>       >         sponsor.
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>> Thanks,
>>>>>       >         >>
>>>>>       >         >>
>>>>> Yasumasa
>>>>>       >         >>
>>>>>       >         >>
>>>>>       > >> [1]
>>>>>       >         >>
>>>>>       >         >> http://icedtea.classpath.org/wiki/HeapStats
>>>>>       > >> [2]
>>>>>       >         >>
>>>>>       >         >> https://github.com/YaSuenag/jlivepatcher
>>>>>       > >> (in
>>>>>       >         >>
>>>>> Japanese)
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >         >>
>>>>>       >
>>>>>       >
>>>>>       >         --
>>>>>       >         Dmitry Samersoff
>>>>>       >         Oracle Java development team, Saint Petersburg, 
>>>>> Russia
>>>>>       >         * I would love to change the world, but they won't
>>>>> give me the
>>>>>       >         sources.
>>>>>       >
>>>>>       >
>>>>>
>>>>>
>>>>>       --
>>>>>       Dmitry Samersoff
>>>>>       Oracle Java development team, Saint Petersburg, Russia
>>>>>       * I would love to change the world, but they won't give me the
>>>>> sources.
>>>>>
>>>>
>>>>
>>
>>



More information about the serviceability-dev mailing list