Re: RFR: JDK-8184770: JDWP support for IPv6

2019-04-11 Thread serguei . spitsyn

Hi Alex,

Great debugging feature!
While I'm still reading all the details, could you, please, fix some 
minor format issues?


http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html

+ * If host is a literal IPv6 address, it may be in square 
brackets. Extra space before "square".



http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html

 I'd suggest to unify comments before functions:
  - start comment with a capital latter and ended with a dot
  - use comment format like this:
   /*
    */

 Examples of comments that need this change:

262 /* result must be release with dbgsysFreeAddrInfo */ => /* * Result 
must be release with dbgsysFreeAddrInfo.  */


325 // input is sockaddr just because all clients have it =>
/* * Input is sockaddr just because all clients have it. */

1129 /* reads boolean system value,
1130 * sets *result to trueValue if the ptoperty is "true",
1131 * to falseValue if the property if "false",
1132 * doesn't change *result if the property is not set or failed to read.
1133 */ => /* * Read boolean system value andset result to: * - 
trueValue if the property is "true"

* - falseValue if the property is "false" *   * Return JNI_OK if result is set, 
return JNI_ERR  otherwise.
*/

 . . .

293 * use IPv6 socket (to accept IPv6 and mapped Ipv4),...
342 * (with AF_INET6 Ipv4 addresses are not parsed even with AI_V4MAPPED 
and AI_ALL flags) ...345 hints.ai_family = AF_UNSPEC; // IPv6 or mapped 
Ipv4 ... 360 } else { // Ipv4 address Replace Ipv4 with IPv4 for 
unification with IPv6

For unification replace: convertIpv4ToIpv6 => convertIPv4ToIPv6

297 hints.ai_flags |= AI_PASSIVE
298 | (allowOnlyIPv4 ? 0 : AI_V4MAPPED | AI_ALL); Better to have just 
one line



1135 JNIEnv* env, . . . 1165 JNIEnv* jniEnv = NULL;

A suggestion is to use the same name for JNIEnv*:

  1135 JNIEnv* jni, . . .
  1165 JNIEnv* jni = NULL;


  Reformat:

608 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 609 || 
(pass == 1 && ai->ai_family != preferredAddressFamily)) and


828 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 829 || 
(pass == 1 && ai->ai_family != preferredAddressFamily)) => if ((pass == 
0 && ai->ai_family == preferredAddressFamily) || (pass == 1 && 
ai->ai_family != preferredAddressFamily))


  Even better, replace it with logical XOR:

if ((pass == 0 ^^ ai->ai_family == preferredAddressFamily)


http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/startListening/startlis001.java.frames.html

102 /* Check that listening address returned by 
ListeningConnector.startListening()

103 * matches the address which was set via connector's arguments.
104 * Empty host address causes listening for local connections only 
(loopback interface)

105 * */ Dot is missed at the end. Replace "* */" with "*/".


http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/jdk/com/sun/jdi/JdwpAllowTest.java.frames.html

162 // generate allow address by changing random bit in the local address
163 // and calculate 2 masks (prefix length) - one is matches original 
local address

164 // and another doesn't. Replace with /* style of comment.


249 positiveTest("PositiveMaskTest(" + test.localAddress + ")", 
test.allowAddress + "/" + test.prefixLengthGood);
250 positiveTest("NegativeMaskTest(" + test.localAddress + ")", 
test.allowAddress + "/" + test.prefixLengthBad);


  A suggestion to move second argument to additional line:

positiveTest("PositiveMaskTest(" + test.localAddress + ")", 
test.allowAddress + "/" + test.prefixLengthGood);
positiveTest("NegativeMaskTest(" + test.localAddress + ")", 
test.allowAddress + "/" + test.prefixLengthBad);


Thanks,
Serguei


On 4/2/19 4:14 PM, Alex Menkov wrote:

Updated webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/

- added support for addresses enclosed in square brackets;
- updated SocketTransportService.java to handle empty hostname the 
same way as JDWP agent (listen/attach to loopback address);

Has to update nsk/jdi/ListeningConnector/startListening/startlis001.java
(all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed).

--alex

On 04/01/2019 11:21, Alex Menkov wrote:

Hi Chris,

On 04/01/2019 04:50, Chris Hegarty wrote:

Alex,

On 29/03/2019 22:07, Alex Menkov wrote:

(added net-dev as suggested by Alan)

Net gurus, please assist in reviewing socket-related code.

New webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/


Specifically on SocketTransportService.java. What Arthur has
proposed is better ( changing to lastIndexOf alone is not
sufficient ). Or is your assumption that the IPv6 literal is
not enclosed in square brackets?


I didn't know about enclosing IPv6 in square brackets, but looks like 
that's standard way to alleviate conflict between IPv6 address and 
colon as port separator.
Will update

Re: JDK-8177064: jcmd help command should not require the process identification

2019-04-11 Thread David Holmes

Hi Gary,

On 12/04/2019 4:24 am, Gary Adams wrote:

Two years ago a request was made to allow

    jcmd help

to be interpretted as a request for help from the current jcmd process
rather than requiring a separate target process to be involved.

Some attempts were made to close the issue, because the
command was not documented to work that way.
It was also pointed out that the help from the running jcmd
might not match the cmds available from a subsequent
request to a different process possibly running a different version
of the vm.

As proof of concept exercise this webrev shows a minimal set of
changes that could support

   jcmd self help

Before fleshing out additional changes in documentation and testing,
I'd like to know if this is still a worth while enhancement. Also,


Given we allow a pid of 0 to mean all Java processes I can see scope for 
a special value that means "the current Java process", but using a text 
word like "self" seems awkward at best. Plus within a shell you can use:


jcmd $$ help

to act on the jcmd VM itself, so there doesn't need to be special 
treatment in that sense. Perhaps some tweaks to the "jcmd -h" text.


I'd like to know more about the history of the checks preventing self 
attach.


This may give you a start: https://bugs.openjdk.java.net/browse/JDK-8177154

Cheers,
David


   Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html
   Issue: https://bugs.openjdk.java.net/browse/JDK-8177064


Re: JDK-8177064: jcmd help command should not require the process identification

2019-04-11 Thread Thomas Stüfe
Hi Gary,

I am not sure this makes sense. jcmd can be used to access wildly different
VMs with different command sets, including Vendor-specific commands (we
have additional commands in the SapMachine, for instance). Also, jcmd is
up- and downward compatible, and you can run older jcmd versions against
newer VMs.

So I do not think the list of commands of the VM jcmd happens to run under
has any relation to the capabilities of the VMs one plans to attach to.

Cheers Thomas




On Thu, Apr 11, 2019 at 8:23 PM Gary Adams  wrote:

> Two years ago a request was made to allow
>
> jcmd help
>
> to be interpretted as a request for help from the current jcmd process
> rather than requiring a separate target process to be involved.
>
> Some attempts were made to close the issue, because the
> command was not documented to work that way.
> It was also pointed out that the help from the running jcmd
> might not match the cmds available from a subsequent
> request to a different process possibly running a different version
> of the vm.
>
> As proof of concept exercise this webrev shows a minimal set of
> changes that could support
>
>jcmd self help
>
> Before fleshing out additional changes in documentation and testing,
> I'd like to know if this is still a worth while enhancement. Also,
> I'd like to know more about the history of the checks preventing self
> attach.
>
>Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html
>Issue: https://bugs.openjdk.java.net/browse/JDK-8177064
>


JDK-8177064: jcmd help command should not require the process identification

2019-04-11 Thread Gary Adams

Two years ago a request was made to allow

   jcmd help

to be interpretted as a request for help from the current jcmd process
rather than requiring a separate target process to be involved.

Some attempts were made to close the issue, because the
command was not documented to work that way.
It was also pointed out that the help from the running jcmd
might not match the cmds available from a subsequent
request to a different process possibly running a different version
of the vm.

As proof of concept exercise this webrev shows a minimal set of
changes that could support

  jcmd self help

Before fleshing out additional changes in documentation and testing,
I'd like to know if this is still a worth while enhancement. Also,
I'd like to know more about the history of the checks preventing self 
attach.


  Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html
  Issue: https://bugs.openjdk.java.net/browse/JDK-8177064