Re: RFR(S): JDK-8165496 assert(_exception_caught == false) failed: _exception_caught is out of phase

[serguei.spit...@oracle.com]

Hi Dmitry,

Sorry, I do not see how this fixes the problem.
What are you trying to solve by calling the set_exception_detected() 
conditionally?

The _exception_detected flag at that point has to be set anyway, right?

The root cause of this issue is that the assert is unreasonable and does 
not solve anything.
So that the assert has to be replaced with cleaning the 
_exception_caught flag.

Please, read my comment in the bug report.
I also thought that you were agree with this conclusion. :)

Thanks,
Serguei


On 10/21/16 01:42, Dmitry Samersoff wrote:

Everybody,

Please review a small modification of the fix for JDK-8134434:

http://cr.openjdk.java.net/~dsamersoff/JDK-8165496/webrev.04/

Its' possible that we come to rethrow_C when _exception_caught is
already cleared. We need not to set exception_detected in this
case.

-Dmitry

RFR(XS): 8168662: Intrinsic support for event based tracing needs explicit control dependency

[Markus Gronlund]

Greetings,

 

I recently integrated intrinsic support for event based tracing which was 
tracked in JDK-8166806 (https://bugs.openjdk.java.net/browse/JDK-8166806 ). 

Unfortunately, the changes for 8166806 led to issues seen in testing on SPARC 
and AARCH64 platforms in that the intrinsic code was missing an explicit 
control dependency for C2. On the x86 platform, it seems that there is an 
implicit control dependency that makes the original code work correctly - but 
on the former platforms, the lack of dependency allows a load to "float" up 
before the implicit null check dispatch for the uncommon trap.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8168662 

Webrev: http://cr.openjdk.java.net/~mgronlun/8168662/webrev01/ 

 

I have managed to reproduce and analyze the assembler output for SPARC with the 
updated changes (please see bug for details).

 

I would need to integrate this to resolve some testing issues, so reviews very 
much appreciated.

 

Thanks in advance and sorry for any inconveniences related to 8166806.

 

Best regards

Markus

 

PS also thanks for Nils Eliasson for assistance on this issue.

Re: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present.

[Mandy Chung]

+1
Mandy

> On Oct 25, 2016, at 2:45 AM, Amit Sapre  wrote:
> 
> Thanks Mandy for the review. I incorporated your comments and updated changes 
> are available in this webrev.
> http://cr.openjdk.java.net/~asapre/webrev/8151099/webrev.02/ 
> 
> PS: Also updated copyright year for all modified files.
> 
> Amit
> 
>> -Original Message-
>> From: Mandy Chung
>> Sent: Tuesday, October 25, 2016 3:24 AM
>> To: Amit Sapre
>> Cc: serviceability-dev; Daniel Fuchs; David Holmes
>> Subject: Re: RFR : JDK-8151099 :
>> java.lang.management.ManagementFactory.getPlatformMXBeans() should work
>> even if jdk.management is not present.
>> 
>> 
>>> On Oct 24, 2016, at 5:49 AM, Amit Sapre 
>> wrote:
>>> 
>>> Hello,
>>> 
>>> I have incorporate review comments and updated changes are available
>> in this webrev:
>>> Updated Webrev :
>> http://cr.openjdk.java.net/~asapre/webrev/8151099/webrev.01/
>>> 
>> 
>> Looks okay to me.
>> 
>> sun/management/VMManagementImpl.java
>> 106 try {
>> 107
>> Class.forName("com.sun.management.GarbageCollectorMXBean");
>> 108 } catch (Exception x) {
>> 
>> ==> catch specific exception would be better e.g.
>> ClassNotFoundException
>> 
>> 109   isSupported = false;
>> 
>> Nit: 4-space indent
>> 
>> jdk/test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNot
>> ificationContentTest.java
>>  75 final Boolean isNotificationSupported =
>> test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotific
>> ationTest.java
>>  74 final Boolean isNotificationSupported =
>> 
>> It can use “boolean” primitive type.
>> 
>> DefaultManagementProviderTest.java
>>  Can you break the long @summary line
>> 
>> Mandy

Re: RFR(XS): 8165881 - Backout JDK-8164913

[Dmitry Samersoff]

Yasumasa,

> Should I change the Assignee on JBS (JDK-8165869) to you?

Yes. Please do it.

-Dmitry

On 2016-10-25 12:29, Yasumasa Suenaga wrote:
> Hi Dmitry,
> 
>> It's hard to fix this issue without access to Oracle testing
>> infrastructure.
> 
> Agree.
> I'm not an Oracle employee. Thus I cannot access it.
> 
> Should I change the Assignee on JBS (JDK-8165869) to you?
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/10/25 15:09, Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> It's hard to fix this issue without access to Oracle testing
>> infrastructure.
>>
>> I'm working on the issue but unfortunately I was caught by some internal
>> problems so it progresses slowly than I expected.
>>
>> I'm sorry about it.
>>
>> -Dmitry
>>
>>
>> On 2016-10-24 13:24, Yasumasa Suenaga wrote:
>>> Hi Dmitry, David,
>>>
>>> I want to resume to work for this issue because this issue has been
>>> marked P3.
>>> Dmitry, do you have any idea for it?
>>>
>>> IMHO, we can fix as below:
>>>
>>>   http://cr.openjdk.java.net/~ysuenaga/JDK-8165869/webrev.00/
>>>
>>> According to David, JvmtiExport::load_agent_library() should return zero
>>> when the operation which is kicked by AttachListener is succeeded.
>>> AttachListener will write response code from
>>> JvmtiExport::load_agent_library() at first, and the client (e.g.
>>> HotSpotVirtualMachine.java) checks it.
>>>
>>> Thus I keep current implementation about return code, and I added the
>>> code to send error message to the client.
>>> It works fine with jdk/test/com/sun/tools/attach/BasicTests.java .
>>>
>>> What do you think about it?
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/09/15 20:08, Dmitry Samersoff wrote:
 Yasumasa, David,

 I'm looking into this issue and come back as soon as I have a clear
 picture.

 It takes some time. Sorry!

 -Dmitry

 On 2016-09-15 14:01, Yasumasa Suenaga wrote:
> Hi David,
>
> I agree the call sequence which you write in the case of "jcmd"
> operation.
> However, we should think about "load" operation in AttachListener.
>
> We can access JvmtiExport::load_agent_library() through two routes:
>
>  Route "load": AttachListener -> JvmtiExport::load_agent_library()
>  Route "jcmd": AttachListener -> jcmd() in attachListener.cpp ->
> DCmd::parse_and_execute()
>
> "load" sets error code (it means first data in the stream) when
> JvmtiExport::load_agent_library() returns JNI_ERR.
> OTOH "jcmd" sets error code if exception is occurred ONLY.
>
> If we try to load invalid JVMTI agent, "load" writes JNI_ERR to
> stream,
> however "jcmd" writes JNI_OK because pending exception is not
> available
> at this point.
> Currently, JCmd.java shows "Command executed successfully" when it
> cannot read the message from the socket. In case of this issue,
> JVMTIAgentLoadDCmd does not write any message because it cannot attach
> the agent.
> If return code which is in the top of stream should mean whether
> communication with AttachListener is succeeded, I think HotSpot should
> write error message or error code to the stream for JCmd.java .
>
> I'm not sure this email is the answer for you.
> Sorry for my English.
>
>
> Yasumasa
>
>
> On 2016/09/15 18:43, David Holmes wrote:
>> Hi Yasumasa,
>>
>> On 15/09/2016 1:56 PM, Yasumasa Suenaga wrote:
>>> Hi,
>>>
 If this is done through jcmd then jcmd needs to know how to
 "unwrap"
 the information it gets back from the Dcmd.
>>>
>>> In case of JVMTI.agent_load dcmd, I think we should be able to
>>> get the
>>> response as below:
>>>
>>>   1. Invalid JVMTI agent
>>>   2. Agent_OnAttach() did not return JNI_OK
>>>   3. Succeeded
>>>
>>> Currently, JvmtiExport::load_agent_library() returns JNI_OK to
>>> caller,
>>> and jcmd() in attachListener.cpp returns JNI_ERR if exception is
>>> occurred (in Agent_OnAttach()).
>>
>> Can you respond to my comment in the bug report about the chain of
>> calls and explain exactly where you think things are going wrong in
>> this scenario. I'm having a lot of trouble trying to see how the
>> information flows back through the layers.
>>
>>> IMHO, HotSpot should return error code (in top of the stream:
>>> written by
>>> AttachListener at first). So we should be able to get some error
>>> code in
>>> case 1. and 2. Then the client (jcmd or other methods) can decide to
>>> parse text information in the stream.
>>
>> It returns the high-level response code first "did communication with
>> the target VM succeed", then the actual action response code. That
>> seems the right thing to do to me. It is up to the callers reading
>> the
>> stream to understand how to read it. To me the issue lies
>> somewhere on
>> the jcmd/dcmd side.

Re: RFR(XS): 8165881 - Backout JDK-8164913

[David Holmes]

On 25/10/2016 7:28 PM, Yasumasa Suenaga wrote:

Hi David,


The completion status will be 0 because we did manage to communicate
with the target VM and process the DCmd request. It passes sis back up
to the caller. So looking at JCmd.java I see:

   try (InputStream in = hvm.executeJCmd(line);) {
// read to EOF and just print output
byte b[] = new byte[256];
int n;
boolean messagePrinted = false;
do {
n = in.read(b);
if (n > 0) {
String s = new String(b, 0, n, "UTF-8");
System.out.print(s);
messagePrinted = true;
}
} while (n > 0);
if (!messagePrinted) {
System.out.println("Command executed successfully");
}
}

and that logic, AFAICS, is not parsing out a return code followed by
an error message!


IMHO, JCmd#executeCommandForPid() should not parse return code from DCmd
because most of DCmds will not return the code.
For example, HelpDCmd and SystemGCDcmd will not return it.


I can't look at this at the moment, but there is a wire protocol here 
that needs to be followed, and if it isn't followed then that needs to 
be fixed. If all of Dcmd needs some updates then so be it.


David

PS. I am about to travel and will be offline till Wednesday afternoon US 
PST.



If we should parse return code in JCmd.java, I guess we have to add
return code to all
DCmds. IMHO, they should be fixed on another issue.

Thanks,

Yasumasa



On 2016/10/25 12:41, David Holmes wrote:

On 24/10/2016 8:24 PM, Yasumasa Suenaga wrote:

Hi Dmitry, David,

I want to resume to work for this issue because this issue has been
marked P3.
Dmitry, do you have any idea for it?

IMHO, we can fix as below:

  http://cr.openjdk.java.net/~ysuenaga/JDK-8165869/webrev.00/

According to David, JvmtiExport::load_agent_library() should return zero
when the operation which is kicked by AttachListener is succeeded.
AttachListener will write response code from
JvmtiExport::load_agent_library() at first, and the client (e.g.
HotSpotVirtualMachine.java) checks it.

Thus I keep current implementation about return code, and I added the
code to send error message to the client.
It works fine with jdk/test/com/sun/tools/attach/BasicTests.java .

What do you think about it?


Sorry but I still see the problem as being in the JCmd code, as per my
previous email on the subject. [1]

David
-

[1]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-September/024546.html






Thanks,

Yasumasa


On 2016/09/15 20:08, Dmitry Samersoff wrote:

Yasumasa, David,

I'm looking into this issue and come back as soon as I have a clear
picture.

It takes some time. Sorry!

-Dmitry

On 2016-09-15 14:01, Yasumasa Suenaga wrote:

Hi David,

I agree the call sequence which you write in the case of "jcmd"
operation.
However, we should think about "load" operation in AttachListener.

We can access JvmtiExport::load_agent_library() through two routes:

 Route "load": AttachListener -> JvmtiExport::load_agent_library()
 Route "jcmd": AttachListener -> jcmd() in attachListener.cpp ->
DCmd::parse_and_execute()

"load" sets error code (it means first data in the stream) when
JvmtiExport::load_agent_library() returns JNI_ERR.
OTOH "jcmd" sets error code if exception is occurred ONLY.

If we try to load invalid JVMTI agent, "load" writes JNI_ERR to
stream,
however "jcmd" writes JNI_OK because pending exception is not
available
at this point.
Currently, JCmd.java shows "Command executed successfully" when it
cannot read the message from the socket. In case of this issue,
JVMTIAgentLoadDCmd does not write any message because it cannot attach
the agent.
If return code which is in the top of stream should mean whether
communication with AttachListener is succeeded, I think HotSpot should
write error message or error code to the stream for JCmd.java .

I'm not sure this email is the answer for you.
Sorry for my English.


Yasumasa


On 2016/09/15 18:43, David Holmes wrote:

Hi Yasumasa,

On 15/09/2016 1:56 PM, Yasumasa Suenaga wrote:

Hi,


If this is done through jcmd then jcmd needs to know how to
"unwrap"
the information it gets back from the Dcmd.


In case of JVMTI.agent_load dcmd, I think we should be able to
get the
response as below:

  1. Invalid JVMTI agent
  2. Agent_OnAttach() did not return JNI_OK
  3. Succeeded

Currently, JvmtiExport::load_agent_library() returns JNI_OK to
caller,
and jcmd() in attachListener.cpp returns JNI_ERR if exception is
occurred (in Agent_OnAttach()).


Can you respond to my comment in the bug report about the chain of
calls and explain exactly where you think things are going wrong in
this scenario. I'm having a lot of trouble trying to see how the
information flows back through the layers.


IMHO, HotSpot should return error code (in top of the 

RE: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present.

[Amit Sapre]

Thanks Mandy for the review. I incorporated your comments and updated changes 
are available in this webrev.
http://cr.openjdk.java.net/~asapre/webrev/8151099/webrev.02/ 

PS: Also updated copyright year for all modified files.

Amit

> -Original Message-
> From: Mandy Chung
> Sent: Tuesday, October 25, 2016 3:24 AM
> To: Amit Sapre
> Cc: serviceability-dev; Daniel Fuchs; David Holmes
> Subject: Re: RFR : JDK-8151099 :
> java.lang.management.ManagementFactory.getPlatformMXBeans() should work
> even if jdk.management is not present.
> 
> 
> > On Oct 24, 2016, at 5:49 AM, Amit Sapre 
> wrote:
> >
> > Hello,
> >
> > I have incorporate review comments and updated changes are available
> in this webrev:
> > Updated Webrev :
> http://cr.openjdk.java.net/~asapre/webrev/8151099/webrev.01/
> >
> 
> Looks okay to me.
> 
> sun/management/VMManagementImpl.java
>  106 try {
>  107
> Class.forName("com.sun.management.GarbageCollectorMXBean");
>  108 } catch (Exception x) {
> 
> ==> catch specific exception would be better e.g.
> ClassNotFoundException
> 
>  109   isSupported = false;
> 
> Nit: 4-space indent
> 
> jdk/test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNot
> ificationContentTest.java
>   75 final Boolean isNotificationSupported =
> test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotific
> ationTest.java
>   74 final Boolean isNotificationSupported =
> 
> It can use “boolean” primitive type.
> 
> DefaultManagementProviderTest.java
>   Can you break the long @summary line
> 
> Mandy

Re: RFR(XS): 8165881 - Backout JDK-8164913

[Yasumasa Suenaga]

Hi Dmitry,


It's hard to fix this issue without access to Oracle testing infrastructure.


Agree.
I'm not an Oracle employee. Thus I cannot access it.

Should I change the Assignee on JBS (JDK-8165869) to you?


Thanks,

Yasumasa


On 2016/10/25 15:09, Dmitry Samersoff wrote:

Yasumasa,

It's hard to fix this issue without access to Oracle testing infrastructure.

I'm working on the issue but unfortunately I was caught by some internal
problems so it progresses slowly than I expected.

I'm sorry about it.

-Dmitry


On 2016-10-24 13:24, Yasumasa Suenaga wrote:

Hi Dmitry, David,

I want to resume to work for this issue because this issue has been
marked P3.
Dmitry, do you have any idea for it?

IMHO, we can fix as below:

  http://cr.openjdk.java.net/~ysuenaga/JDK-8165869/webrev.00/

According to David, JvmtiExport::load_agent_library() should return zero
when the operation which is kicked by AttachListener is succeeded.
AttachListener will write response code from
JvmtiExport::load_agent_library() at first, and the client (e.g.
HotSpotVirtualMachine.java) checks it.

Thus I keep current implementation about return code, and I added the
code to send error message to the client.
It works fine with jdk/test/com/sun/tools/attach/BasicTests.java .

What do you think about it?


Thanks,

Yasumasa


On 2016/09/15 20:08, Dmitry Samersoff wrote:

Yasumasa, David,

I'm looking into this issue and come back as soon as I have a clear
picture.

It takes some time. Sorry!

-Dmitry

On 2016-09-15 14:01, Yasumasa Suenaga wrote:

Hi David,

I agree the call sequence which you write in the case of "jcmd"
operation.
However, we should think about "load" operation in AttachListener.

We can access JvmtiExport::load_agent_library() through two routes:

 Route "load": AttachListener -> JvmtiExport::load_agent_library()
 Route "jcmd": AttachListener -> jcmd() in attachListener.cpp ->
DCmd::parse_and_execute()

"load" sets error code (it means first data in the stream) when
JvmtiExport::load_agent_library() returns JNI_ERR.
OTOH "jcmd" sets error code if exception is occurred ONLY.

If we try to load invalid JVMTI agent, "load" writes JNI_ERR to stream,
however "jcmd" writes JNI_OK because pending exception is not available
at this point.
Currently, JCmd.java shows "Command executed successfully" when it
cannot read the message from the socket. In case of this issue,
JVMTIAgentLoadDCmd does not write any message because it cannot attach
the agent.
If return code which is in the top of stream should mean whether
communication with AttachListener is succeeded, I think HotSpot should
write error message or error code to the stream for JCmd.java .

I'm not sure this email is the answer for you.
Sorry for my English.


Yasumasa


On 2016/09/15 18:43, David Holmes wrote:

Hi Yasumasa,

On 15/09/2016 1:56 PM, Yasumasa Suenaga wrote:

Hi,


If this is done through jcmd then jcmd needs to know how to "unwrap"
the information it gets back from the Dcmd.


In case of JVMTI.agent_load dcmd, I think we should be able to get the
response as below:

  1. Invalid JVMTI agent
  2. Agent_OnAttach() did not return JNI_OK
  3. Succeeded

Currently, JvmtiExport::load_agent_library() returns JNI_OK to caller,
and jcmd() in attachListener.cpp returns JNI_ERR if exception is
occurred (in Agent_OnAttach()).


Can you respond to my comment in the bug report about the chain of
calls and explain exactly where you think things are going wrong in
this scenario. I'm having a lot of trouble trying to see how the
information flows back through the layers.


IMHO, HotSpot should return error code (in top of the stream:
written by
AttachListener at first). So we should be able to get some error
code in
case 1. and 2. Then the client (jcmd or other methods) can decide to
parse text information in the stream.


It returns the high-level response code first "did communication with
the target VM succeed", then the actual action response code. That
seems the right thing to do to me. It is up to the callers reading the
stream to understand how to read it. To me the issue lies somewhere on
the jcmd/dcmd side.

Thanks,
David



Sorry for my English.

Yasumasa


On 2016/09/14 7:03, David Holmes wrote:

On 13/09/2016 10:31 PM, Yasumasa Suenaga wrote:

Thanks David!
If we should not change the meaning of return code from
JvmtiExport::load_agent_library(), we should print return code as
below:
---
diff -r 0cf03b9d9b1f src/share/vm/prims/jvmtiExport.cpp
--- a/src/share/vm/prims/jvmtiExport.cppMon Sep 12 18:59:13 2016
+
+++ b/src/share/vm/prims/jvmtiExport.cppTue Sep 13 21:12:14 2016
+0900
@@ -2412,6 +2412,10 @@
   result = JNI_OK;
 }
   }
+ // Print error code if Agent_OnAttach cannot be executed
+ if (result != JNI_OK) {
+ st->print_cr("%d", result);
+ }
   return result;
 }
---


Not sure I see the point. "return result" will put the error code
into
the socket stream and that error will be seen and responded to. I
don't 

Re: RFR(XS): 8165881 - Backout JDK-8164913

[Dmitry Samersoff]

Yasumasa,

It's hard to fix this issue without access to Oracle testing infrastructure.

I'm working on the issue but unfortunately I was caught by some internal
problems so it progresses slowly than I expected.

I'm sorry about it.

-Dmitry


On 2016-10-24 13:24, Yasumasa Suenaga wrote:
> Hi Dmitry, David,
> 
> I want to resume to work for this issue because this issue has been
> marked P3.
> Dmitry, do you have any idea for it?
> 
> IMHO, we can fix as below:
> 
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8165869/webrev.00/
> 
> According to David, JvmtiExport::load_agent_library() should return zero
> when the operation which is kicked by AttachListener is succeeded.
> AttachListener will write response code from
> JvmtiExport::load_agent_library() at first, and the client (e.g.
> HotSpotVirtualMachine.java) checks it.
> 
> Thus I keep current implementation about return code, and I added the
> code to send error message to the client.
> It works fine with jdk/test/com/sun/tools/attach/BasicTests.java .
> 
> What do you think about it?
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/09/15 20:08, Dmitry Samersoff wrote:
>> Yasumasa, David,
>>
>> I'm looking into this issue and come back as soon as I have a clear
>> picture.
>>
>> It takes some time. Sorry!
>>
>> -Dmitry
>>
>> On 2016-09-15 14:01, Yasumasa Suenaga wrote:
>>> Hi David,
>>>
>>> I agree the call sequence which you write in the case of "jcmd"
>>> operation.
>>> However, we should think about "load" operation in AttachListener.
>>>
>>> We can access JvmtiExport::load_agent_library() through two routes:
>>>
>>>  Route "load": AttachListener -> JvmtiExport::load_agent_library()
>>>  Route "jcmd": AttachListener -> jcmd() in attachListener.cpp ->
>>> DCmd::parse_and_execute()
>>>
>>> "load" sets error code (it means first data in the stream) when
>>> JvmtiExport::load_agent_library() returns JNI_ERR.
>>> OTOH "jcmd" sets error code if exception is occurred ONLY.
>>>
>>> If we try to load invalid JVMTI agent, "load" writes JNI_ERR to stream,
>>> however "jcmd" writes JNI_OK because pending exception is not available
>>> at this point.
>>> Currently, JCmd.java shows "Command executed successfully" when it
>>> cannot read the message from the socket. In case of this issue,
>>> JVMTIAgentLoadDCmd does not write any message because it cannot attach
>>> the agent.
>>> If return code which is in the top of stream should mean whether
>>> communication with AttachListener is succeeded, I think HotSpot should
>>> write error message or error code to the stream for JCmd.java .
>>>
>>> I'm not sure this email is the answer for you.
>>> Sorry for my English.
>>>
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/09/15 18:43, David Holmes wrote:
 Hi Yasumasa,

 On 15/09/2016 1:56 PM, Yasumasa Suenaga wrote:
> Hi,
>
>> If this is done through jcmd then jcmd needs to know how to "unwrap"
>> the information it gets back from the Dcmd.
>
> In case of JVMTI.agent_load dcmd, I think we should be able to get the
> response as below:
>
>   1. Invalid JVMTI agent
>   2. Agent_OnAttach() did not return JNI_OK
>   3. Succeeded
>
> Currently, JvmtiExport::load_agent_library() returns JNI_OK to caller,
> and jcmd() in attachListener.cpp returns JNI_ERR if exception is
> occurred (in Agent_OnAttach()).

 Can you respond to my comment in the bug report about the chain of
 calls and explain exactly where you think things are going wrong in
 this scenario. I'm having a lot of trouble trying to see how the
 information flows back through the layers.

> IMHO, HotSpot should return error code (in top of the stream:
> written by
> AttachListener at first). So we should be able to get some error
> code in
> case 1. and 2. Then the client (jcmd or other methods) can decide to
> parse text information in the stream.

 It returns the high-level response code first "did communication with
 the target VM succeed", then the actual action response code. That
 seems the right thing to do to me. It is up to the callers reading the
 stream to understand how to read it. To me the issue lies somewhere on
 the jcmd/dcmd side.

 Thanks,
 David

>
> Sorry for my English.
>
> Yasumasa
>
>
> On 2016/09/14 7:03, David Holmes wrote:
>> On 13/09/2016 10:31 PM, Yasumasa Suenaga wrote:
>>> Thanks David!
>>> If we should not change the meaning of return code from
>>> JvmtiExport::load_agent_library(), we should print return code as
>>> below:
>>> ---
>>> diff -r 0cf03b9d9b1f src/share/vm/prims/jvmtiExport.cpp
>>> --- a/src/share/vm/prims/jvmtiExport.cppMon Sep 12 18:59:13 2016
>>> +
>>> +++ b/src/share/vm/prims/jvmtiExport.cppTue Sep 13 21:12:14 2016
>>> +0900
>>> @@ -2412,6 +2412,10 @@
>>>result = JNI_OK;
>>>  }
>>>}
>>> + //