From brian.burkhalter at oracle.com Mon Feb 4 19:48:06 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Feb 2019 11:48:06 -0800 Subject: adding rsockets support into JDK In-Reply-To: <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> Message-ID: <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> Do we have sufficient convergence on the javadoc verbiage in jdk.net.{RdmaSocketOptions,RdmaSockets} to update the CSR content so it can move to re-review and be finalized? I can provide a specdiff if need be. Thanks, Brian > On Jan 31, 2019, at 9:13 AM, Brian Burkhalter wrote: > > Thanks, Chris > >> On Jan 31, 2019, at 8:58 AM, Chris Hegarty > wrote: >> >> I integrated these changes ( that closely match Lucy's patch ): >> >> - rsocket-branch: Review comments from Brian, A, B, and D >> http://hg.openjdk.java.net/jdk/sandbox/rev/1e1db86ea836 >> >> - rsocket-branch: Review comment C from Brian - rename dispatcher >> http://hg.openjdk.java.net/jdk/sandbox/rev/3e1ebe33554c >> >> - rsocket-branch: Additional test coverage for the RDMA selector provider >> http://hg.openjdk.java.net/jdk/sandbox/rev/abd18a34acbf -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Mon Feb 4 19:51:37 2019 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 4 Feb 2019 19:51:37 +0000 Subject: adding rsockets support into JDK In-Reply-To: <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> Hi Brian, I was about to ask the same question just now :) I think we already addressed all the feedbacks. However, Alan/Chris, please let us know if there is anything else we need to change in terms of JavaDoc wording. Thanks, Lucy From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Brian Burkhalter Sent: Monday, February 4, 2019 11:48 AM To: nio-dev at openjdk.java.net Cc: Viswanathan, Sandhya ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Do we have sufficient convergence on the javadoc verbiage in jdk.net.{RdmaSocketOptions,RdmaSockets} to update the CSR content so it can move to re-review and be finalized? I can provide a specdiff if need be. Thanks, Brian On Jan 31, 2019, at 9:13 AM, Brian Burkhalter > wrote: Thanks, Chris On Jan 31, 2019, at 8:58 AM, Chris Hegarty > wrote: I integrated these changes ( that closely match Lucy's patch ): - rsocket-branch: Review comments from Brian, A, B, and D http://hg.openjdk.java.net/jdk/sandbox/rev/1e1db86ea836 - rsocket-branch: Review comment C from Brian - rename dispatcher http://hg.openjdk.java.net/jdk/sandbox/rev/3e1ebe33554c - rsocket-branch: Additional test coverage for the RDMA selector provider http://hg.openjdk.java.net/jdk/sandbox/rev/abd18a34acbf -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 4 21:58:03 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Feb 2019 13:58:03 -0800 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> Message-ID: <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> Hi Lucy, I found and fixed some small errors in the RdmaSockets doc: http://hg.openjdk.java.net/jdk/sandbox/rev/78d016915473 I also have some doubts about the accuracy of the documentation in this class regarding socket options. Firstly, the options supported by the objects returned by openSocket() and openSocketChannel() look as if they do not include *all* the options supported by java.net.Socket and java.net.ServerSocket, respectively, contrary to the documentation, e.g., "An RDMA socket supports the same socket options that java.net.Socket defines. In addition, it supports the socket options specified by RdmaSocketOptions .?. In addition to the RDMA socket options, the RDMA socket and socket channel appear to support SO_SNDBUF, SO_RCVBUF, SO_REUSEADDR, and TCP_NODELAY which are only a proper subset of the options supported by Socket{Channel} and what one would expect based on [1]. Secondly, openServerSocketChannel() does not include the sentence "In addition, it supports the socket options specified by RdmaSocketOptions .? but looks like it should. Thirdly, the documentation of openServerSocketChannel() does not mention options at all which appears to be an omission. I am happy to update this documentation as needed once there is corroboration or rejection of my foregoing comments. Thanks, Brian [1] https://linux.die.net/man/7/rsocket > On Feb 4, 2019, at 11:51 AM, Lu, Yingqi wrote: > > I think we already addressed all the feedbacks. However, Alan/Chris, please let us know if there is anything else we need to change in terms of JavaDoc wording. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 4 22:04:21 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Feb 2019 14:04:21 -0800 Subject: adding rsockets support into JDK In-Reply-To: <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> Message-ID: <832C4AEF-D0F0-4485-A94C-9FAFD1BB19B5@oracle.com> > On Feb 4, 2019, at 1:58 PM, Brian Burkhalter wrote: > > Secondly, openServerSocketChannel() does not include the sentence > > "In addition, it supports the socket options specified by RdmaSocketOptions .? > > but looks like it should. Correction: in the snippet above I actually intended ?openServerSocket()? instead of ?openServertSocketChannel().? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Mon Feb 4 22:42:22 2019 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 4 Feb 2019 22:42:22 +0000 Subject: adding rsockets support into JDK In-Reply-To: <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> Hi Brian, You are right! Rdma socket and server socket do not support all the available Standard Socket Options. Here is the list: RdmaSocket{Channel} supports following socket options: StandardSocketOptions.SO_SNDBUF StandardSocketOptions.SO_RCVBUF StandardSocketOptions.SO_REUSEADDR StandardSocketOptions.TCP_NODELAY RDMASocketOptions. RDMA_SQSIZE RDMASocketOptions. RDMA_RQSIZE RDMASocketOptions. RDMA_INLINE RdmaServerSocket{Channel} supports following socket options: StandardSocketOptions.SO_RCVBUF StandardSocketOptions.SO_REUSEADDR RDMASocketOptions. RDMA_SQSIZE RDMASocketOptions. RDMA_RQSIZE RDMASocketOptions. RDMA_INLINE Please help update them! Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Monday, February 4, 2019 1:58 PM To: Lu, Yingqi Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, I found and fixed some small errors in the RdmaSockets doc: http://hg.openjdk.java.net/jdk/sandbox/rev/78d016915473 I also have some doubts about the accuracy of the documentation in this class regarding socket options. Firstly, the options supported by the objects returned by openSocket() and openSocketChannel() look as if they do not include *all* the options supported by java.net.Socket and java.net.ServerSocket, respectively, contrary to the documentation, e.g., "An RDMA socket supports the same socket options that java.net.Socket defines. In addition, it supports the socket options specified by RdmaSocketOptions.?. In addition to the RDMA socket options, the RDMA socket and socket channel appear to support SO_SNDBUF, SO_RCVBUF, SO_REUSEADDR, and TCP_NODELAY which are only a proper subset of the options supported by Socket{Channel} and what one would expect based on [1]. Secondly, openServerSocketChannel() does not include the sentence "In addition, it supports the socket options specified by RdmaSocketOptions.? but looks like it should. Thirdly, the documentation of openServerSocketChannel() does not mention options at all which appears to be an omission. I am happy to update this documentation as needed once there is corroboration or rejection of my foregoing comments. Thanks, Brian [1] https://linux.die.net/man/7/rsocket On Feb 4, 2019, at 11:51 AM, Lu, Yingqi > wrote: I think we already addressed all the feedbacks. However, Alan/Chris, please let us know if there is anything else we need to change in terms of JavaDoc wording. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 4 22:46:39 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Feb 2019 14:46:39 -0800 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> Message-ID: <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> Hi Lucy, > On Feb 4, 2019, at 2:42 PM, Lu, Yingqi wrote: > > Here is the list: > > [?] That matches what I found. > Please help update them! Will do, perhaps after further (lack of) comment. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 5 19:48:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Feb 2019 11:48:08 -0800 Subject: 8218460: Test generation scripts do not invoke stream preprocessor correctly Message-ID: <99683428-4D82-4A83-92FC-F34950F97B7F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8218460 http://cr.openjdk.java.net/~bpb/8218460/webrev.00/ A full test run will be effected with the generated tests except those generated by test/jdk/java/lang/invoke/VarHandles/generate-vh-tests.sh Unfortunately it appears that tests in this folder were modified by manual editing as opposed to modifying the templates and generating the tests via the script. This will be the subject of a linked issue. Thanks, Brian From Roger.Riggs at oracle.com Tue Feb 5 20:46:50 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 5 Feb 2019 15:46:50 -0500 Subject: 8218460: Test generation scripts do not invoke stream preprocessor correctly In-Reply-To: <99683428-4D82-4A83-92FC-F34950F97B7F@oracle.com> References: <99683428-4D82-4A83-92FC-F34950F97B7F@oracle.com> Message-ID: <09038658-9603-2b79-74d4-a031498bb200@oracle.com> The changes look fine. Thanks, Roger On 02/05/2019 02:48 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8218460 > http://cr.openjdk.java.net/~bpb/8218460/webrev.00/ > > A full test run will be effected with the generated tests except those generated by > > test/jdk/java/lang/invoke/VarHandles/generate-vh-tests.sh > > Unfortunately it appears that tests in this folder were modified by manual editing as opposed to modifying the templates and generating the tests via the script. This will be the subject of a linked issue. > > Thanks, > > Brian From brian.burkhalter at oracle.com Tue Feb 5 22:24:15 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Feb 2019 14:24:15 -0800 Subject: adding rsockets support into JDK In-Reply-To: <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> Message-ID: <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> Hi Lucy, Specification of options in jdk.net.RdmaSockets updated: http://hg.openjdk.java.net/jdk/sandbox/rev/87484051dbba If there are no more comments on the jdk.net javadoc then I think the CSR can be updated and then re-reviewed. I?d maybe hold off until tomorrow to update the CSR. Thanks, Brian > On Feb 4, 2019, at 2:46 PM, Brian Burkhalter wrote: > >> Please help update them! > > Will do, perhaps after further (lack of) comment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Tue Feb 5 22:25:25 2019 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Tue, 5 Feb 2019 22:25:25 +0000 Subject: adding rsockets support into JDK In-Reply-To: <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> References: <59ecdb38-8d20-3416-602c-47198fac6e41@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C116B@ORSMSX113.amr.corp.intel.com> <503229EF-747A-4783-B985-0DB0D647194E@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15C2B69@ORSMSX113.amr.corp.intel.com> <9e3dff33-9beb-00ff-0285-d73266ae6f39@oracle.com> <6E49F5A9-AFB7-472D-99E7-07EFBF02FF62@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15E56C9@ORSMSX113.amr.corp.intel.com> <2339ec72-1298-8bf0-d5ec-b7f18f2739a5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603228@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16039C3@ORSMSX113.amr.corp.intel.com> <323783EB-F0A4-4195-970F-D42CFEF20A37@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1603DEA@ORSMSX113.amr.corp.intel.com> <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD161175C@ORSMSX113.amr.corp.intel.com> Thank you for the help, Brian!! Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Tuesday, February 5, 2019 2:24 PM To: Lu, Yingqi Cc: nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, Specification of options in jdk.net.RdmaSockets updated: http://hg.openjdk.java.net/jdk/sandbox/rev/87484051dbba If there are no more comments on the jdk.net javadoc then I think the CSR can be updated and then re-reviewed. I?d maybe hold off until tomorrow to update the CSR. Thanks, Brian On Feb 4, 2019, at 2:46 PM, Brian Burkhalter > wrote: Please help update them! Will do, perhaps after further (lack of) comment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Feb 6 15:57:10 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Feb 2019 15:57:10 +0000 Subject: adding rsockets support into JDK In-Reply-To: <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> References: <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> Message-ID: <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> Brian, On 05/02/2019 22:24, Brian Burkhalter wrote: > Hi Lucy, > > Specification of options in jdk.net.RdmaSockets updated: > > http://hg.openjdk.java.net/jdk/sandbox/rev/87484051dbba Thanks for catching the spec issue regarding options. Regarding "... defined by java.net.Socket.", I don't think that this is true, anymore. The previous statement deferred the list-of-options to that of the list-of-options that are defined by java.net.Socket. After your change ( which lists the set of options ), then there is no longer need to refer to j.n.Socket, right? Maybe just drop the "defined by java.net.Socket" ( the options are defined in StandardSocketOptions ). -Chris. From brian.burkhalter at oracle.com Wed Feb 6 16:04:16 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 08:04:16 -0800 Subject: adding rsockets support into JDK In-Reply-To: <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> References: <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> Message-ID: <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> Chris, > On Feb 6, 2019, at 7:57 AM, Chris Hegarty wrote: > > Maybe just drop the "defined by > java.net.Socket" ( the options are defined in StandardSocketOptions ). I concur. I was wondering about this wording myself. I?ll remove it. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Feb 6 17:27:29 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Feb 2019 17:27:29 +0000 Subject: adding rsockets support into JDK In-Reply-To: References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> Message-ID: <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> On 06/02/2019 17:24, Brian Burkhalter wrote: > >> On Feb 6, 2019, at 8:04 AM, Brian Burkhalter >> > wrote: >> >>> On Feb 6, 2019, at 7:57 AM, Chris Hegarty >> > wrote: >>> >>> Maybe just drop the "defined by >>> java.net.Socket" ( the options are defined in StandardSocketOptions ). >> >> >> I concur. I was wondering about this wording myself. I?ll remove it. > > Updated: http://hg.openjdk.java.net/jdk/sandbox/rev/95c486f5c444 > > Lucy, unless there are objections I think you can go ahead and update > the CSR for re-review accordingly after which it can be finalized. Agreed. -Chris. From brian.burkhalter at oracle.com Wed Feb 6 17:24:00 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 09:24:00 -0800 Subject: adding rsockets support into JDK In-Reply-To: <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> References: <769ef1e0-76a2-21b0-8b9e-0fb1b44b6cec@oracle.com> <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> Message-ID: > On Feb 6, 2019, at 8:04 AM, Brian Burkhalter wrote: > >> On Feb 6, 2019, at 7:57 AM, Chris Hegarty > wrote: >> >> Maybe just drop the "defined by >> java.net.Socket" ( the options are defined in StandardSocketOptions ). > > > I concur. I was wondering about this wording myself. I?ll remove it. Updated: http://hg.openjdk.java.net/jdk/sandbox/rev/95c486f5c444 Lucy, unless there are objections I think you can go ahead and update the CSR for re-review accordingly after which it can be finalized. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Wed Feb 6 20:34:26 2019 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 6 Feb 2019 20:34:26 +0000 Subject: adding rsockets support into JDK In-Reply-To: <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> I do not see a stage named as "re-review" so that I updated the CSR to "finalized". Thanks for all the help! Lucy >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Wednesday, February 6, 2019 9:27 AM >To: Brian Burkhalter ; Lu, Yingqi > >Cc: Viswanathan, Sandhya ; nio- >dev at openjdk.java.net; Aundhe, Shirish ; Kaczmarek, >Eric >Subject: Re: adding rsockets support into JDK > >On 06/02/2019 17:24, Brian Burkhalter wrote: >> >>> On Feb 6, 2019, at 8:04 AM, Brian Burkhalter >>> > wrote: >>> >>>> On Feb 6, 2019, at 7:57 AM, Chris Hegarty >>> > wrote: >>>> >>>> Maybe just drop the "defined by >>>> java.net.Socket" ( the options are defined in StandardSocketOptions ). >>> >>> >>> I concur. I was wondering about this wording myself. I?ll remove it. >> >> Updated: http://hg.openjdk.java.net/jdk/sandbox/rev/95c486f5c444 >> >> Lucy, unless there are objections I think you can go ahead and update >> the CSR for re-review accordingly after which it can be finalized. > >Agreed. > >-Chris. From brian.burkhalter at oracle.com Wed Feb 6 21:25:47 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 13:25:47 -0800 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Lucy, > On Feb 6, 2019, at 12:34 PM, Lu, Yingqi wrote: > > I do not see a stage named as "re-review" so that I updated the CSR to "finalized?. That should be fine. People can still add comments if necessary. > Thanks for all the help! You?re welcome! I also updated the copyright year: http://hg.openjdk.java.net/jdk/sandbox/rev/81e4a12fd1a4. Existing files now have the more recent year as 2019 and new files have 2019 only. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 6 21:45:41 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 13:45:41 -0800 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> Message-ID: <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> It looks as if the link http://cr.openjdk.java.net/~ylu/rsocket_docs/api/jdk.net/jdk/net/package-summary.html in the CSR [1] does not point to the current javadoc and the attached rsocket_docs.zip is from Dec. 4, 2018. Probably I should create and attach a specdiff as well. Brian [1] https://bugs.openjdk.java.net/browse/JDK-8205186 > On Feb 6, 2019, at 12:34 PM, Lu, Yingqi wrote: > > I do not see a stage named as "re-review" so that I updated the CSR to "finalized". -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 6 22:15:14 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 14:15:14 -0800 Subject: adding rsockets support into JDK In-Reply-To: <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> Message-ID: Hi Lucy, Specdiff attached to CSR. I suggest removing the out of date link and attached Zip of docs mentioned below. Thanks, Brian > On Feb 6, 2019, at 1:45 PM, Brian Burkhalter wrote: > > It looks as if the link http://cr.openjdk.java.net/~ylu/rsocket_docs/api/jdk.net/jdk/net/package-summary.html in the CSR [1] does not point to the current javadoc and the attached rsocket_docs.zip is from Dec. 4, 2018. Probably I should create and attach a specdiff as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Wed Feb 6 22:28:19 2019 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 6 Feb 2019 22:28:19 +0000 Subject: adding rsockets support into JDK In-Reply-To: References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD16139C5@ORSMSX113.amr.corp.intel.com> Done! Just removed it. Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Wednesday, February 6, 2019 2:15 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; Viswanathan, Sandhya ; nio-dev at openjdk.java.net; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, Specdiff attached to CSR. I suggest removing the out of date link and attached Zip of docs mentioned below. Thanks, Brian On Feb 6, 2019, at 1:45 PM, Brian Burkhalter > wrote: It looks as if the link http://cr.openjdk.java.net/~ylu/rsocket_docs/api/jdk.net/jdk/net/package-summary.html in the CSR [1] does not point to the current javadoc and the attached rsocket_docs.zip is from Dec. 4, 2018. Probably I should create and attach a specdiff as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 6 22:30:19 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 14:30:19 -0800 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD16139C5@ORSMSX113.amr.corp.intel.com> References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16139C5@ORSMSX113.amr.corp.intel.com> Message-ID: <36F7DE0B-D71C-413F-A7F4-EC6AF6F9FEBC@oracle.com> Cool! You might also want to blow away the sentence "Online Javadoc: http://cr.openjdk.java.net/~ylu/rsocket_docs/api/jdk.net/jdk/net/package-summary.html ? if the link target is out of date (as it is). Thanks, Brian > On Feb 6, 2019, at 2:28 PM, Lu, Yingqi wrote: > > Done! Just removed it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 6 22:34:34 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Feb 2019 14:34:34 -0800 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1613A48@ORSMSX113.amr.corp.intel.com> References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16139C5@ORSMSX113.amr.corp.intel.com> <36F7DE0B-D71C-413F-A7F4-EC6AF6F9FEBC@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1613A48@ORSMSX113.amr.corp.intel.com> Message-ID: <33A4027B-77B3-4124-8C28-191B93BEE38B@oracle.com> Hi Lucy, Great! Now it should be good to go. Thanks, Brian > On Feb 6, 2019, at 2:33 PM, Lu, Yingqi wrote: > > Good catch! I just removed the sentence as well J > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Wed Feb 6 22:33:56 2019 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 6 Feb 2019 22:33:56 +0000 Subject: adding rsockets support into JDK In-Reply-To: <36F7DE0B-D71C-413F-A7F4-EC6AF6F9FEBC@oracle.com> References: <82C3FAB4-8E83-4C25-8B0C-2EB087D8C2B3@oracle.com> <7F89914C-BDF2-4F4C-A951-B7E26DFC6354@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607889@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1607DC9@ORSMSX113.amr.corp.intel.com> <874D5D8B-7D68-4FC5-BB7C-31A9574A9E6D@oracle.com> <6EC4F433-836E-4C39-A3FF-F20D9011F211@oracle.com> <366D4B99-D966-4B89-8935-791D01ECC917@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16139C5@ORSMSX113.amr.corp.intel.com> <36F7DE0B-D71C-413F-A7F4-EC6AF6F9FEBC@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1613A48@ORSMSX113.amr.corp.intel.com> Hi Brian, Good catch! I just removed the sentence as well ? Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Wednesday, February 6, 2019 2:30 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; Viswanathan, Sandhya ; nio-dev at openjdk.java.net; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Cool! You might also want to blow away the sentence "Online Javadoc: http://cr.openjdk.java.net/~ylu/rsocket_docs/api/jdk.net/jdk/net/package-summary.html? if the link target is out of date (as it is). Thanks, Brian On Feb 6, 2019, at 2:28 PM, Lu, Yingqi > wrote: Done! Just removed it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 7 13:42:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Feb 2019 13:42:46 +0000 Subject: adding rsockets support into JDK In-Reply-To: <33A4027B-77B3-4124-8C28-191B93BEE38B@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16139C5@ORSMSX113.amr.corp.intel.com> <36F7DE0B-D71C-413F-A7F4-EC6AF6F9FEBC@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1613A48@ORSMSX113.amr.corp.intel.com> <33A4027B-77B3-4124-8C28-191B93BEE38B@oracle.com> Message-ID: On 06/02/2019 22:34, Brian Burkhalter wrote: > Hi Lucy, > > Great! Now it should be good to go. > I went through the javadoc. Overall I think it looks good but there are a few places where it can be tweaked a bit to be consistent with the existing wording in StandardSocketOption, ServerSocketChannel and a few other places. There is also one or two places where the links are a bit strange, e.g. openServerSocketChannel was incorrectly linking to methods in SocketChannel. Finally, we can put a statement in the RdmaSockets class description to avoid the @throws NPE in all methods. I've pushed a change to the sandbox with these tweaks. I hope that is okay (I realize we risk too many cooks here but the sandbox is great for this sort of collaboration). -Alan [1] http://hg.openjdk.java.net/jdk/sandbox/rev/12c7d6b3ec28 From brian.burkhalter at oracle.com Thu Feb 7 16:01:39 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Feb 2019 08:01:39 -0800 Subject: adding rsockets support into JDK In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD160E256@ORSMSX113.amr.corp.intel.com> <88D4A8AE-3B58-4740-B657-0B54D596B4D8@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD160FA1D@ORSMSX113.amr.corp.intel.com> <570AFF36-988B-4C5A-AFDC-F57C45248236@oracle.com> <5DBC93F6-66B7-4624-8E95-E7BA95FEA146@oracle.com> <7a569f67-7ec6-3d2b-1402-52e3550132a3@oracle.com> <5A1586F1-D9B5-426E-B0D7-465A258CE410@oracle.com> <082b2706-0dcd-f236-3f59-cc28a2ae5cd5@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16130DC@ORSMSX113.amr.corp.intel.com> <0168CC2F-2A3E-4253-B853-1196A5799F14@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD16139C5@ORSMSX113.amr.corp.intel.com> <36F7DE0B-D71C-413F-A7F4-EC6AF6F9FEBC@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1613A48@ORSMSX113.amr.corp.intel.com> <33A4027B-77B3-4124-8C28-191B93BEE38B@oracle.com> Message-ID: > On Feb 7, 2019, at 5:42 AM, Alan Bateman wrote: > > I've pushed a change to the sandbox with these tweaks. I?ll update the specdiff attachment to the CSR some time today. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 8 23:08:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Feb 2019 15:08:27 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods Message-ID: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> Continuing the thread [1] from October, 2018 regarding [2]. The webrev [3] includes mainly the template files, not source nor test files generated therefrom. The following methods are added to the $Type$Buffer classes where $Type$ is in {Byte, Char, Double, Float, Int, Long, Short} and, respectively, $type$ is in {byte, char, double, float, int, long, short}: public $Type$Buffer get(int index, $type$[] dst, int offset, int length) {} public $Type$Buffer get(int index, $type$[] dst) {} public $Type$Buffer put(int index, $type$[] src, int offset, int length) {} public $Type$Buffer put(int index, $type$[] src) {} public $Type$Buffer put(int index, $Type$Buffer src, int offset, int length) {} In addition to the changes implied by the foregoing, there is a javadoc fix at line 843 / 927, and ?@throws NullPointerException? is removed at line 437 as it is redundant with the package documentation. (I know there are some commented out print statements; they?ll be excised later.) Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-October/005517.html [2] https://bugs.openjdk.java.net/browse/JDK-5029431 [3] http://cr.openjdk.java.net/~bpb/5029431/webrev.00 From Ulf.Zibis at CoSoCo.de Sat Feb 9 13:37:04 2019 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 9 Feb 2019 14:37:04 +0100 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> Message-ID: Hi, couldn't you take advantage of System.arraycopy() or some performancing intrinsics? -Ulf Am 09.02.19 um 00:08 schrieb Brian Burkhalter: > Continuing the thread [1] from October, 2018 regarding [2]. > > The webrev [3] includes mainly the template files, not source nor test files generated therefrom. > > [3] http://cr.openjdk.java.net/~bpb/5029431/webrev.00 From Alan.Bateman at oracle.com Sat Feb 9 13:50:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 9 Feb 2019 13:50:06 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> Message-ID: <6d04803b-570f-dfa8-1668-73165012abe1@oracle.com> On 09/02/2019 13:37, Ulf Zibis wrote: > Hi, > > couldn't you take advantage of System.arraycopy() or some performancing > intrinsics? > Which case are you concerned about? I haven't had time to study the latest revision but it should already be using Unsafe copyMemory or arraycopy for all the bulk copy cases. -Alan From Ulf.Zibis at CoSoCo.de Sat Feb 9 15:18:52 2019 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 9 Feb 2019 16:18:52 +0100 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <6d04803b-570f-dfa8-1668-73165012abe1@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <6d04803b-570f-dfa8-1668-73165012abe1@oracle.com> Message-ID: Am 09.02.19 um 14:50 schrieb Alan Bateman: > On 09/02/2019 13:37, Ulf Zibis wrote: >> Hi, >> >> couldn't you take advantage of System.arraycopy() or some performancing >> intrinsics? >> > Which case are you concerned about? I haven't had time to study the > latest revision but it should already be using Unsafe copyMemory or > arraycopy for all the bulk copy cases. I only had looked into *X-Buffer.java.template*, where a normal for loop is used, for *Heap-X-Buffer.java.template* and *Direct-X-Buffer.java.template* you are right. -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Feb 10 16:17:30 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Feb 2019 16:17:30 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> Message-ID: <66e81db1-e735-0a82-3647-7431aac16d3a@oracle.com> On 08/02/2019 23:08, Brian Burkhalter wrote: > Continuing the thread [1] from October, 2018 regarding [2]. > > The webrev [3] includes mainly the template files, not source nor test files generated therefrom. The following methods are added to the $Type$Buffer classes where $Type$ is in {Byte, Char, Double, Float, Int, Long, Short} and, respectively, $type$ is in {byte, char, double, float, int, long, short}: > > public $Type$Buffer get(int index, $type$[] dst, int offset, int length) {} > public $Type$Buffer get(int index, $type$[] dst) {} > public $Type$Buffer put(int index, $type$[] src, int offset, int length) {} > public $Type$Buffer put(int index, $type$[] src) {} > public $Type$Buffer put(int index, $Type$Buffer src, int offset, int length) {} > > In addition to the changes implied by the foregoing, there is a javadoc fix at line 843 / 927, and ?@throws NullPointerException? is removed at line 437 as it is redundant with the package documentation. > > (I know there are some commented out print statements; they?ll be excised later.) > The signatures of the first 4 methods look right, the javadoc looks good too. I'm just mulling over the case where there are fewer than `length` bytes between the index and the limit. The relative bulk get/put will throw BufferUnderflowException or BufferOverflowException for these cases. I realize we touched on this in an earlier iteration but looking at it now then I think we need to re-examine that point to decide on the exceptions. put(index, src, offset, length) need discussion and okay to move to a separate issue if you want. The absolute version of put(src) is put(index, src), going further would be put(index, src, srcIndex, int length). The rename of "offset" to "srcIndex" is deliberate as it would be too easy to assume the offset is from the buffer's position. Another thing to mention is that put(src) throws IAE when you the source is the same buffer. If you are allow the source to be the same buffer in the absolute version then it will need to specify how overlapping regions are handled. -Alan From chris.hegarty at oracle.com Mon Feb 11 10:15:24 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 11 Feb 2019 10:15:24 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <66e81db1-e735-0a82-3647-7431aac16d3a@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <66e81db1-e735-0a82-3647-7431aac16d3a@oracle.com> Message-ID: <305B9C1B-6750-44F7-8D55-F5CA59B3A25D@oracle.com> Brian, Overall I think this is very good, and I'm happy to see it moving forward. > On 10 Feb 2019, at 16:17, Alan Bateman wrote: > > On 08/02/2019 23:08, Brian Burkhalter wrote: >> Continuing the thread [1] from October, 2018 regarding [2]. >> >> The webrev [3] includes mainly the template files, not source nor test files generated therefrom. The following methods are added to the $Type$Buffer classes where $Type$ is in {Byte, Char, Double, Float, Int, Long, Short} and, respectively, $type$ is in {byte, char, double, float, int, long, short}: >> >> public $Type$Buffer get(int index, $type$[] dst, int offset, int length) {} >> public $Type$Buffer get(int index, $type$[] dst) {} >> public $Type$Buffer put(int index, $type$[] src, int offset, int length) {} >> public $Type$Buffer put(int index, $type$[] src) {} A very minor comment regarding the `index` param description: "The index *in this buffer from/at which the first* $type$ will be read/written" >> public $Type$Buffer put(int index, $Type$Buffer src, int offset, int length) {} >> >> In addition to the changes implied by the foregoing, there is a javadoc fix at line 843 / 927, and ?@throws NullPointerException? is removed at line 437 as it is redundant with the package documentation. >> >> (I know there are some commented out print statements; they?ll be excised later.) >> > The signatures of the first 4 methods look right, the javadoc looks good too. I'm just mulling over the case where there are fewer than `length` bytes between the index and the limit. The relative bulk get/put will throw BufferUnderflowException or BufferOverflowException for these cases. I realize we touched on this in an earlier iteration but looking at it now then I think we need to re-examine that point to decide on the exceptions. AFAIK current index / precondition checks regarding a buffer's space availability result in Buffer[Under|Over]flowException. Array based precondition checks result in IndexOutOfBoundsException. Might be best to keep the current model. > put(index, src, offset, length) need discussion and okay to move to a separate issue if you want. The absolute version of put(src) is put(index, src), going further would be put(index, src, srcIndex, int length). The rename of "offset" to "srcIndex" is deliberate as it would be too easy to assume the offset is from the buffer's position. Another thing to mention is that put(src) throws IAE when you the source is the same buffer. If you are allow the source to be the same buffer in the absolute version then it will need to specify how overlapping regions are handled. Wow, this one could be tricky if both this buffer and src are allowed to be the same. Straight forward if not. I can see the use-case of shuffling around some data in a single buffer, which will work fine once there is no overlapping region. I think this is a reasonable use-case, but will have to see how allowing such will impact on the API. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Mon Feb 11 15:12:33 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 11 Feb 2019 10:12:33 -0500 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> Message-ID: Hi Brian, With two buffer/arrays and each with offset and length, I think the exceptions should identify which set of parameters is out of range. Using Preconditions.checkFromIndexSize directly would allow providing a formatter that could identify the source or dest. In the examples, use the full parameter names instead of abbreviations. 780, 1008: "off" -> "offset" since offset is used in the prose 826, 1057, add a colon ":" after "invocation" $.02, Roger On 02/08/2019 06:08 PM, Brian Burkhalter wrote: > Continuing the thread [1] from October, 2018 regarding [2]. > > The webrev [3] includes mainly the template files, not source nor test files generated therefrom. The following methods are added to the $Type$Buffer classes where $Type$ is in {Byte, Char, Double, Float, Int, Long, Short} and, respectively, $type$ is in {byte, char, double, float, int, long, short}: > > public $Type$Buffer get(int index, $type$[] dst, int offset, int length) {} > public $Type$Buffer get(int index, $type$[] dst) {} > public $Type$Buffer put(int index, $type$[] src, int offset, int length) {} > public $Type$Buffer put(int index, $type$[] src) {} > public $Type$Buffer put(int index, $Type$Buffer src, int offset, int length) {} > > In addition to the changes implied by the foregoing, there is a javadoc fix at line 843 / 927, and ?@throws NullPointerException? is removed at line 437 as it is redundant with the package documentation. > > (I know there are some commented out print statements; they?ll be excised later.) > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-October/005517.html > [2] https://bugs.openjdk.java.net/browse/JDK-5029431 > [3] http://cr.openjdk.java.net/~bpb/5029431/webrev.00 From brian.burkhalter at oracle.com Mon Feb 11 17:32:39 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Feb 2019 09:32:39 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <305B9C1B-6750-44F7-8D55-F5CA59B3A25D@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <66e81db1-e735-0a82-3647-7431aac16d3a@oracle.com> <305B9C1B-6750-44F7-8D55-F5CA59B3A25D@oracle.com> Message-ID: <16F6C315-49CE-45A3-BF9F-C3CAB1C43952@oracle.com> Hi Alan, Chris, Thanks for the comments. > On Feb 11, 2019, at 2:15 AM, Chris Hegarty wrote: > >> >> On 10 Feb 2019, at 16:17, Alan Bateman > wrote: >> >>> [?] > > A very minor comment regarding the `index` param description: > > "The index *in this buffer from/at which the first* $type$ will be > read/written? I agree that that is better; will update accordingly. >> The signatures of the first 4 methods look right, the javadoc looks good too. I'm just mulling over the case where there are fewer than `length` bytes between the index and the limit. The relative bulk get/put will throw BufferUnderflowException or BufferOverflowException for these cases. I realize we touched on this in an earlier iteration but looking at it now then I think we need to re-examine that point to decide on the exceptions. > > AFAIK current index / precondition checks regarding a buffer's space > availability result in Buffer[Under|Over]flowException. Array based > precondition checks result in IndexOutOfBoundsException. Might be best > to keep the current model. It really is kind of a toss up, no? One advantage of using Buffer*flowException would be differentiating whether ?this? or the parameter {array, buffer} would have an out of bounds access. >> put(index, src, offset, length) need discussion and okay to move to a separate issue if you want. The absolute version of put(src) is put(index, src), going further would be put(index, src, srcIndex, int length). The rename of "offset" to "srcIndex" is deliberate as it would be too easy to assume the offset is from the buffer's position. Another thing to mention is that put(src) throws IAE when you the source is the same buffer. If you are allow the source to be the same buffer in the absolute version then it will need to specify how overlapping regions are handled. > > Wow, this one could be tricky if both this buffer and src are allowed > to be the same. Straight forward if not. I can see the use-case of > shuffling around some data in a single buffer, which will work fine once > there is no overlapping region. I think this is a reasonable use-case, > but will have to see how allowing such will impact on the API. In the case of the relative method, the state of ?this? and the parameter buffer are both being modified which would cause problems if they were the same buffer. That is not the case here. I wonder whether the same buffer should be allowed without restriction thereby leaving it to the user to ensure that there is no problem? Or would that be too much of a free for all? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 11 17:35:26 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Feb 2019 09:35:26 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> Message-ID: <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> Hi Roger, Thanks for the comments. > On Feb 11, 2019, at 7:12 AM, Roger Riggs wrote: > > With two buffer/arrays and each with offset and length, I think the exceptions > should identify which set of parameters is out of range. > Using Preconditions.checkFromIndexSize directly would allow providing a formatter > that could identify the source or dest. As buffers are used during startup would this cause problems? > In the examples, use the full parameter names instead of abbreviations. > > 780, 1008: "off" -> "offset" since offset is used in the prose > > 826, 1057, add a colon ":" after "invocation" Agreed on both; shall update. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Mon Feb 11 18:05:57 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 11 Feb 2019 13:05:57 -0500 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> Message-ID: Hi Brian, On 02/11/2019 12:35 PM, Brian Burkhalter wrote: > Hi Roger, > > Thanks for the comments. > >> On Feb 11, 2019, at 7:12 AM, Roger Riggs > > wrote: >> >> With two buffer/arrays and each with offset and length, I think the >> exceptions >> should identify which set of parameters is out of range. >> Using Preconditions.checkFromIndexSize directly would allow providing >> a formatter >> that could identify the source or dest. > > As buffers are used during startup would this cause problems? Not a problem, that is the same method invoked from Objects.checkFromToIndex but has an argument to generate the exception. (Which can be a instance of a static class if lambda is ruled out due to startup sequence). $.02, Roger > >> In the examples, use the full parameter names instead of abbreviations. >> >> 780, 1008: "off" -> "offset" since offset is used in the prose >> >> 826, 1057, add a colon ":" after "invocation" > > Agreed on both; shall update. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Feb 11 18:11:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Feb 2019 18:11:46 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> Message-ID: <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> On 11/02/2019 18:05, Roger Riggs wrote: > >>> On Feb 11, 2019, at 7:12 AM, Roger Riggs >> > wrote: >>> >>> With two buffer/arrays and each with offset and length, I think the >>> exceptions >>> should identify which set of parameters is out of range. >>> Using Preconditions.checkFromIndexSize directly would allow >>> providing a formatter >>> that could identify the source or dest. >> >> As buffers are used during startup would this cause problems? > Not a problem, that is the same method invoked from > Objects.checkFromToIndex > but has an argument to generate the exception. > (Which can be a instance of a static class if lambda is ruled out due > to startup sequence). I don't think we want any formatters or anything that uses the service provider mechanism here. In any case, the check is for later, I think we first need to establish what the right exceptions are when there is buffer overflow/underflow. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 11 18:13:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Feb 2019 10:13:27 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> Message-ID: <242C3D5E-30D5-44B7-B7BC-FF1401427861@oracle.com> > On Feb 11, 2019, at 10:11 AM, Alan Bateman wrote: > > On 11/02/2019 18:05, Roger Riggs wrote: >> >>>> On Feb 11, 2019, at 7:12 AM, Roger Riggs > wrote: >>>> >>>> With two buffer/arrays and each with offset and length, I think the exceptions >>>> should identify which set of parameters is out of range. >>>> Using Preconditions.checkFromIndexSize directly would allow providing a formatter >>>> that could identify the source or dest. >>> >>> As buffers are used during startup would this cause problems? >> Not a problem, that is the same method invoked from Objects.checkFromToIndex >> but has an argument to generate the exception. >> (Which can be a instance of a static class if lambda is ruled out due to startup sequence). > I don't think we want any formatters or anything that uses the service provider mechanism here. In any case, the check is for later, I think we first need to establish what the right exceptions are when there is buffer overflow/underflow. Agreed. I was just writing the same. If the exceptions were different it would disambiguate the circumstance to a certain degree. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 11 18:32:09 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Feb 2019 10:32:09 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <305B9C1B-6750-44F7-8D55-F5CA59B3A25D@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <66e81db1-e735-0a82-3647-7431aac16d3a@oracle.com> <305B9C1B-6750-44F7-8D55-F5CA59B3A25D@oracle.com> Message-ID: <38F24AC9-E6CE-44DE-8F12-F33181640743@oracle.com> > On Feb 11, 2019, at 2:15 AM, Chris Hegarty wrote: > > A very minor comment regarding the `index` param description: > > "The index *in this buffer from/at which the first* $type$ will be > read/written" > On Feb 11, 2019, at 7:12 AM, Roger Riggs wrote: > > > In the examples, use the full parameter names instead of abbreviations. > > 780, 1008: "off" -> "offset" since offset is used in the prose > > 826, 1057, add a colon ":" after ?invocation" The foregoing changes are applied in: http://cr.openjdk.java.net/~bpb/5029431/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Mon Feb 11 18:52:52 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 11 Feb 2019 13:52:52 -0500 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> Message-ID: <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> Hi Alan, There are not formatters or providers involved, it is just a method to create the exception;? so that a? disambiguating message text can be supplied. Roger On 02/11/2019 01:11 PM, Alan Bateman wrote: > > > On 11/02/2019 18:05, Roger Riggs wrote: >> >>>> On Feb 11, 2019, at 7:12 AM, Roger Riggs >>> > wrote: >>>> >>>> With two buffer/arrays and each with offset and length, I think the >>>> exceptions >>>> should identify which set of parameters is out of range. >>>> Using Preconditions.checkFromIndexSize directly would allow >>>> providing a formatter >>>> that could identify the source or dest. >>> >>> As buffers are used during startup would this cause problems? >> Not a problem, that is the same method invoked from >> Objects.checkFromToIndex >> but has an argument to generate the exception. >> (Which can be a instance of a static class if lambda is ruled out due >> to startup sequence). > I don't think we want any formatters or anything that uses the service > provider mechanism here. In any case, the check is for later, I think > we first need to establish what the right exceptions are when there is > buffer overflow/underflow. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Feb 11 19:29:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Feb 2019 19:29:09 +0000 Subject: NIO based SocketImpl to replace legacy PlainSocketImpl In-Reply-To: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com> References: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com> Message-ID: On 25/01/2019 14:08, Alan Bateman wrote: > > I've created a branch in the sandbox, named "niosocketimpl-branch", > with a prototype SocketImpl implementation based on the infrastructure > in sun.nio.ch package that supports the NIO channel implementations. > The branch also includes the changes to java.net.Socket and > ServerSocket to use this SocketImpl by default. Just a quick update on this effort. Michael has changed the SOCKS and HTTP proxy SocketImpl implementations to use delegation rather than sub-classing so they can delegate to the new NIO based SocketImpl or the old PlainSocketImpl. We've added a system property so you can run with -Djdk.net.usePlainSocketImpl or -Djdk.net.usePlainSocketImpl=true to use the old implementation. Existing tests are passing with both the old and new implementations so I think this effort is starting to look good. I expect we will be at the point soon where we could use some help from those with libraries or applications that use the old Socket/ServerSocket APIs extensively. -Alan From brian.burkhalter at oracle.com Mon Feb 11 22:30:20 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Feb 2019 14:30:20 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> Message-ID: > On Feb 11, 2019, at 10:52 AM, Roger Riggs wrote: > > There are not formatters or providers involved, it is just a method > to create the exception; so that a disambiguating message text can be supplied. Thanks for clarifying. > On Feb 11, 2019, at 2:15 AM, Chris Hegarty wrote: > >> The signatures of the first 4 methods look right, the javadoc looks good too. I'm just mulling over the case where there are fewer than `length` bytes between the index and the limit. The relative bulk get/put will throw BufferUnderflowException or BufferOverflowException for these cases. I realize we touched on this in an earlier iteration but looking at it now then I think we need to re-examine that point to decide on the exceptions. > > AFAIK current index / precondition checks regarding a buffer's space > availability result in Buffer[Under|Over]flowException. Array based > precondition checks result in IndexOutOfBoundsException. Might be best > to keep the current model. The presence of the absolute index into the buffer complicates the situation. In the absolute get() to an array, for example, get(index,$type$[],offset,length) throwing a BufferUnderflowException would make sense for 0 <= index < limit() && index + length > limit(), but if index < 0 or index > limit() an IOOBE appears more logical. Likewise for put(index,$type$[],offset,length), a BufferOverflowException would work for 0 <= index < limit() && index + length > limit, but IOOBE again seems more apropos for index < 0 or index > limit(). For any given method where an IOOBE could be thrown for different indexes being out of bounds, then a better disambiguation message as Roger suggested would be helpful. If an IOOBE can be thrown by only one particular index being out of range, then the default checkFromIndexSize() message might be enough. For example, for the code byte[] ba = new byte[42]; bb.put(-1, ba, 0, 42); the exception java.lang.IndexOutOfBoundsException: Range [-1, -1 + 42) out of bounds for length 42 is thrown which looks to be sufficient if we know a priori which index is involved. For the method put(index,$Type$Buffer,offset,length) the BufferUnderflowException would be for ?src? not having enough elements to copy to ?this? and the BufferOverflowException for ?this? not having enough space before limit() to contain the copied elements. Again, either ?index? or ?offset? being out of range would be better handled by an IOOBE. Note that using Buffer*flowException would require an update to the specifications of these exceptions as now they are described as being specific to relative operations. Currently (before this patch) the bounds check is done by java.nio.Buffer.checkBounds(). If we are using Objects.checkFromIndexSize() or Preconditions here it would be good to replace all uses of checkBounds(). Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 12 01:58:33 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 Feb 2019 17:58:33 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <38F24AC9-E6CE-44DE-8F12-F33181640743@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <66e81db1-e735-0a82-3647-7431aac16d3a@oracle.com> <305B9C1B-6750-44F7-8D55-F5CA59B3A25D@oracle.com> <38F24AC9-E6CE-44DE-8F12-F33181640743@oracle.com> Message-ID: <613B15B5-BBAC-42AF-BD4F-836675849507@oracle.com> > On Feb 11, 2019, at 10:32 AM, Brian Burkhalter wrote: > [?] > > The foregoing changes are applied in: > > http://cr.openjdk.java.net/~bpb/5029431/webrev.01/ > On Feb 10, 2019, at 8:17 AM, Alan Bateman wrote: > > put(index, src, offset, length) need discussion and okay to move to a separate issue if you want. The absolute version of put(src) is put(index, src), going further would be put(index, src, srcIndex, int length). The rename of "offset" to "srcIndex" is deliberate as it would be too easy to assume the offset is from the buffer's position. Another thing to mention is that put(src) throws IAE when you the source is the same buffer. If you are allow the source to be the same buffer in the absolute version then it will need to specify how overlapping regions are handled. The above webrev is further updated in place to address the comments in the preceding paragraph regarding offset -> srcIndex and handling the same buffer. The method put(index,src) is not (yet) added. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 12 08:49:38 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Feb 2019 08:49:38 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> Message-ID: On 11/02/2019 22:30, Brian Burkhalter wrote: > > The presence of the absolute index into the buffer complicates the > situation. In the absolute get() to an array, for example, > get(index,$type$[],offset,length) throwing a BufferUnderflowException > would make sense for > > 0 <= index < limit() && index + length > limit(), > > but if index < 0 or index > limit() an IOOBE appears more logical. > Likewise for put(index,$type$[],offset,length), a > BufferOverflowException would work for > > 0 <= index < limit() && index + length > limit, > > but IOOBE again seems more apropos for index < 0 or index > limit(). > For any given method where an IOOBE could be thrown for different > indexes being out of bounds, then a better disambiguation message as > Roger suggested would be helpful. If an IOOBE can be thrown by only > one particular index being out of range, then the default > checkFromIndexSize() message might be enough. For example, for the code > > ? ? ??byte[] ba = new byte[42]; > ? ? ? ? bb.put(-1, ba, 0, 42); > > the exception > > java.lang.IndexOutOfBoundsException: Range [-1, -1 + 42) out of bounds > for length 42 > > is thrown which looks to be sufficient if we know a priori which index > is involved. > > For the method put(index,$Type$Buffer,offset,length) the > BufferUnderflowException would be for ?src? not having enough elements > to copy to ?this? and the BufferOverflowException for ?this? not > having enough space before limit() to contain the copied elements. > Again, either ?index? or ?offset? being out of range would be better > handled by an IOOBE. > > Note that using Buffer*flowException would require an update to the > specifications of these exceptions as now they are described as being > specific to relative operations. > I think you are on the right track with this thinking. That is, throw IOOBE when index is negative or >= limit, throw the Buffer*flowExceptions if the transfer would result in buffer overflow/underflow. I think that will fix the inconsistency with the current proposal and also helps with the troubleshooting a bit. Yes, it does mean a small adjustment to the wording in the exceptions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Feb 12 09:18:17 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Feb 2019 09:18:17 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> Message-ID: <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> > On 12 Feb 2019, at 08:49, Alan Bateman wrote: > > On 11/02/2019 22:30, Brian Burkhalter wrote: >> >> The presence of the absolute index into the buffer complicates the situation. In the absolute get() to an array, for example, get(index,$type$[],offset,length) throwing a BufferUnderflowException would make sense for >> >> 0 <= index < limit() && index + length > limit(), >> >> but if index < 0 or index > limit() an IOOBE appears more logical. Likewise for put(index,$type$[],offset,length), a BufferOverflowException would work for >> >> 0 <= index < limit() && index + length > limit, >> >> but IOOBE again seems more apropos for index < 0 or index > limit(). For any given method where an IOOBE could be thrown for different indexes being out of bounds, then a better disambiguation message as Roger suggested would be helpful. If an IOOBE can be thrown by only one particular index being out of range, then the default checkFromIndexSize() message might be enough. For example, for the code >> >> byte[] ba = new byte[42]; >> bb.put(-1, ba, 0, 42); >> >> the exception >> >> java.lang.IndexOutOfBoundsException: Range [-1, -1 + 42) out of bounds for length 42 >> >> is thrown which looks to be sufficient if we know a priori which index is involved. >> >> For the method put(index,$Type$Buffer,offset,length) the BufferUnderflowException would be for ?src? not having enough elements to copy to ?this? and the BufferOverflowException for ?this? not having enough space before limit() to contain the copied elements. Again, either ?index? or ?offset? being out of range would be better handled by an IOOBE. >> >> Note that using Buffer*flowException would require an update to the specifications of these exceptions as now they are described as being specific to relative operations. >> > I think you are on the right track with this thinking. That is, throw IOOBE when index is negative or >= limit, throw the Buffer*flowExceptions if the transfer would result in buffer overflow/underflow. I think that will fix the inconsistency with the current proposal and also helps with the troubleshooting a bit. Yes, it does mean a small adjustment to the wording in the exceptions. Agreed. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Feb 12 21:57:23 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 12 Feb 2019 21:57:23 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> Message-ID: <3aeba9a64a434a968fc1d82a44077745@sap.com> Hi Alan, all, here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design. http://cr.openjdk.java.net/~clanger/webrevs/8213031.6/ With that patch, the behavior is the following: a) A ZipFileSystem instance by default does NOT support the PosixFileAttributeView. However, it is possible to query for a known attribute named "zip:storedPermissions". Its value can be null to represent no permission information or any set of PosixFileAttribute. b) A ZipFileSystem instance can be created with the property "posix"=true. In that case, PosixFileAttributeView is supported with default values. -> owner: A UserPrincipal with the name of System.getProperty("user.name") if property access is allowed, "" otherwise -> group: A GroupPrincipal with the name "". -> permissions: Set.of(OWNER_READ, OWNER_WRITE, GROUP_READ) The default values can be modified by using the properties "defaultOwner", "defaultGroup" and "defaultPermissions". Implementation wise the ZipFileAttributeView always extends PosixFileAttributeView but behaves different, depending on how it was obtained. Within ZipFileSystem, the Entry inner class is not static any more but always has a reference to the Enclosing ZipFileSystem. That's needed because default owner/group/permission can be set on ZipFileSystem instance level now and the Entry, implementing the FileAttributes needs to know where it belongs to. This seems somewhat logical anyway. The new test "TestPosix" is quite extensive. I had to add 2 permissions to test.policy to allow testing in a restricted environment. Module-info and CSR have been adopted, too. Thanks in advance for reviewing. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 21. Januar 2019 10:17 > To: 'Alan Bateman' > Cc: nio-dev ; OpenJDK Dev list dev at openjdk.java.net>; Java Core Libs ; > Volker Simonis > Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions > > Hi Alan, > > first of all, thank you for your input on this. > > > I think the approach to explore are: > > > > 1. zipfs supports PosixFileAttributeView without subsetting. If > > readAttribute(file, BasicFileAttributes.class) succeeds then > > readAttribute(file, PosixFileAttributes.class) should also succeed, even > > if there aren't permissions encoded in the zip entry's external file > > attributes. It would mean that owner and group return default values, > > and permissions may return a default value. It does mean you can't > > distinguish the default value from "no permissions" but there is > > precedence for that, e.g. mount a FAT32 file system on Linux or Unix > > systems and `stat` a file to have the stat structure populated with > > default uid, gid and mode bits. > > OK, I can see the point that in a PosixFileAttributeView as it is, there's no > place for optionality/null values. However, with this approach the benefits > would be that Files::get/setPosixPermissions would work and that's why I > think we should pursue this. The challenge will be to find reasonable > defaults. > > > 2. zipfs defines a new FileAttributeView that defines read and write > > access to permissions stored in a zip entry's external file attribute. > > As it's a new view then it can define the behavior for the case that the > > zip entry doesn't have permissions. Furthermore it does not need to > > extend BasicFileAttributeView so doesn't need to be concerned with bulk > > access, nor concerned with group/owner. As you know, the attributes API > > allows for both type safe and dynamic access so you have a choice as to > > whether to support both or just dynamic access. With the first then > > jdk.zipfs would export a package with a public interface that defines > > the view. If someone wants type safe access to the permissions attribute > > then you need to import the class. The alternative is to not export any > > packages but just define the view in the module-info. The view its name > > and define the name/type of the permissions attribute, it will also > > define how it behaves when the external attributes aren't populated. In > > usage terms it means reading the permissions will be something like > > Files.readAttribute(file, "zip:permissions") and casting the value to > > Set - not pretty but it avoids depending on a > > JDK-specific API. > > For this approach, there are 2 things I dislike. The first is that I don't think we > should export named packages from module jdk.zipfs that people would > develop Java code against while not being in the Java API. And secondly, this > way would not support using Files::set/getPosixPermissions since the > specification/implementation of that utility method explicitly refers to > PosixFileAttributeView. > > I can imagine something like this: > Zipfs by default implements an own view that offers dynamic, not type safe > access to "zip:permissions" and we'll document this. If a user of zipfs wants > to see full PosixFileAttributeView support with default values, then we > should allow for a creation attribute for the zipfs that can control this. Maybe > we can even allow specifying default values for user, group and permissions > via zipfs attributes. > > I'll work to develop the patch into this direction unless you tell me that this > idea is bogus (if so, then I hope it be soon ??) > > Thanks > Christoph > > From brian.burkhalter at oracle.com Wed Feb 13 01:36:23 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 12 Feb 2019 17:36:23 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> Message-ID: <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> > On Feb 12, 2019, at 1:18 AM, Chris Hegarty > wrote: > >> On 12 Feb 2019, at 08:49, Alan Bateman > wrote: >> >> On 11/02/2019 22:30, Brian Burkhalter wrote: >>> >>> [?] >>> >>> Note that using Buffer*flowException would require an update to the specifications of these exceptions as now they are described as being specific to relative operations. >>> >> I think you are on the right track with this thinking. That is, throw IOOBE when index is negative or >= limit, throw the Buffer*flowExceptions if the transfer would result in buffer overflow/underflow. I think that will fix the inconsistency with the current proposal and also helps with the troubleshooting a bit. Yes, it does mean a small adjustment to the wording in the exceptions. > > Agreed. I have revised the specifications of exceptions for the five methods in question and updated the tests accordingly: http://cr.openjdk.java.net/~bpb/5029431/webrev.02/ I have not yet updated the wording of the Buffer*flowException classes to remove the restriction to relative operations. I can do that once the rest looks good. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Feb 13 15:18:45 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Feb 2019 15:18:45 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> Message-ID: Brian, On 13/02/2019 01:36, Brian Burkhalter wrote: > ... > > I have revised the specifications of exceptions for the five methods in > question and updated the tests accordingly: > > http://cr.openjdk.java.net/~bpb/5029431/webrev.02/ > > I have not yet updated the wording of the Buffer*flowException classes > to remove the restriction to relative operations. I can do that once the > rest looks good. The argument bound checking looks good. -Chris. From Alan.Bateman at oracle.com Wed Feb 13 15:33:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Feb 2019 15:33:33 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <3aeba9a64a434a968fc1d82a44077745@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: On 12/02/2019 21:57, Langer, Christoph wrote: > Hi Alan, all, > > here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design. I don't have time to do a detailed code review right now but I did read the updated proposal and javadoc. Overall I think this looks good, meaning opt-in seems right, as does allow specifying configuration to newFileSystem to override defaults. I think the javadoc changes will need a few iterations but we can get to that once some of the finer details are sorted out. For example, "Posix Support" isn't quite right as this is about optional support for the POSIX view of file attributes rather than complete support for POSIX. Also the "Zip" view of file attributes will need to be fleshed out more (the view name for example). I'm not sure about using ${user.name} and "" as default.? Have you looked at using the zip file owner/group (or owner/owner on Windows) as the default?? Also just wondering if 777 might be more appropriate (maybe you have a reason for choosing 660?). It might be useful to see what Linux, macOS and other operating systems do when mounting a FAT file system. The names of the defaultXXX properties when configuring the zip file look okay. Did you consider using the string representation of the user, group and permissions in the configuration properties? The zip file system provider could support both of course. String might make it a bit easier to create the map of configuration properties when creating the file system e.g Map.of("enablePosixPermissions", "true", "defaultOwner", "joe", "defaultPermissions", "rw-rw---"); -Alan From chris.hegarty at oracle.com Wed Feb 13 18:00:12 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Feb 2019 18:00:12 +0000 Subject: rsocket Issue #2 Message-ID: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> Hi Sean, Lucy, In an attempt to work-around issue #2 (non-blocking connect not making progress, reported in [1] ), I have run into a separate issue with `rpoll`. I think it is a bug, and it will make working-around issue #2 much more difficult ( maybe impracticable ). The behaviour I observe is that, if more than one thread is blocked in a `rpoll` call ( with the same socket and events), and the event is triggered, then only one thread ( rpoll ) will wakeup. I've put together a native test: http://cr.openjdk.java.net/~chegar/rsocket/testBipollar.c This is an issue for the Java API that allows a channel to be registered with more than one selector. It is also a possible issue with a selector racing with finishConnect. These scenarios are not all that common, but still possible. The `rpoll` behaviour I observe is clearly different than regular `poll` ( which will wake up all waiters ). Is this a bug, or expected behaviour of the thread-less rsocket implementation? -Chris. [1] https://mail.openjdk.java.net/pipermail/nio-dev/2018-December/005651.html From yingqi.lu at intel.com Wed Feb 13 18:20:28 2019 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 13 Feb 2019 18:20:28 +0000 Subject: rsocket Issue #2 In-Reply-To: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> Message-ID: <0C6169D2-F3CA-419A-BAAB-3318B29D4167@intel.com> Hi Chris, Thank you very much for helping on this issue. I have not experienced this rpoll issue myself. I think Sean should be able to help here. Hi Sean, Would you please help Chris take a look into it? Thank you!! Lucy Sent from my iPhone > On Feb 13, 2019, at 9:58 AM, Chris Hegarty wrote: > > Hi Sean, Lucy, > > In an attempt to work-around issue #2 (non-blocking connect not making > progress, reported in [1] ), I have run into a separate issue with > `rpoll`. I think it is a bug, and it will make working-around issue #2 > much more difficult ( maybe impracticable ). > > The behaviour I observe is that, if more than one thread is blocked in > a `rpoll` call ( with the same socket and events), and the event is > triggered, then only one thread ( rpoll ) will wakeup. I've put together > a native test: > http://cr.openjdk.java.net/~chegar/rsocket/testBipollar.c > > This is an issue for the Java API that allows a channel to be registered > with more than one selector. It is also a possible issue with a selector > racing with finishConnect. These scenarios are not all that common, but > still possible. > > The `rpoll` behaviour I observe is clearly different than regular > `poll` ( which will wake up all waiters ). Is this a bug, or expected > behaviour of the thread-less rsocket implementation? > > -Chris. > > [1] https://mail.openjdk.java.net/pipermail/nio-dev/2018-December/005651.html From Alan.Bateman at oracle.com Wed Feb 13 20:04:43 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Feb 2019 20:04:43 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> Message-ID: <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> On 13/02/2019 01:36, Brian Burkhalter wrote: > : > > I have revised the specifications of exceptions for the five methods > in question and updated the tests accordingly: > > http://cr.openjdk.java.net/~bpb/5029431/webrev.02/ > > I have not yet updated the wording of the Buffer*flowException classes > to remove the restriction to relative operations. I can do that once > the rest looks good. > I spent a bit of time going through the existing spec to get the various exception cases into my head. I think my concerns and suggestion to keep this consistent with the relative bulk get/set methods were incorrect and that IOOBE is actually the right exception. The methods that I think settle this debate is the absolute get/put methods defined by ByteBuffer for reading/writing primitive values. As an example getLong(index) throws IOOBE if the index is not smaller than the limit minus seven. Sorry for wasting your time on Buffer*flowException, they only come into the picture for methods that need to change the position. -Alan From chris.hegarty at oracle.com Wed Feb 13 22:00:50 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Feb 2019 22:00:50 +0000 Subject: rsocket Issue #2 In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373B3DEA4C1@ORSMSX109.amr.corp.intel.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> <1828884A29C6694DAF28B7E6B8A82373B3DEA4C1@ORSMSX109.amr.corp.intel.com> Message-ID: <30221E7B-916A-45C9-8B74-E3DB9CA682AA@oracle.com> On 13 Feb 2019, at 19:06, Hefty, Sean wrote: >> The `rpoll` behaviour I observe is clearly different than regular >> `poll` ( which will wake up all waiters ). Is this a bug, or expected >> behaviour of the thread-less rsocket implementation? > > This is likely an implementation issue, but the intent should be to mimic poll behavior here. So I would consider this a bug, and it would take some work to figure out how to handle this in a way that doesn't result in races. Sure. Is it possible to get this issue into the librdma bug tracking system, and have it evaluated. -Chris. From lance.andersen at oracle.com Wed Feb 13 22:05:09 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Feb 2019 17:05:09 -0500 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <3aeba9a64a434a968fc1d82a44077745@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: Hi Christoph, Just starting to take a peek at this and noticed one quick thing in your test: ------------ Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") ?????? You do not need the test.dir property or the permission added to test.policy to access it, just reference the jar and it will be created in user.dir which is also writable. Best Lance > On Feb 12, 2019, at 4:57 PM, Langer, Christoph wrote: > > Hi Alan, all, > > here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design. > > http://cr.openjdk.java.net/~clanger/webrevs/8213031.6/ > > With that patch, the behavior is the following: > a) A ZipFileSystem instance by default does NOT support the PosixFileAttributeView. However, it is possible to query for a known attribute named "zip:storedPermissions". Its value can be null to represent no permission information or any set of PosixFileAttribute. > b) A ZipFileSystem instance can be created with the property "posix"=true. In that case, PosixFileAttributeView is supported with default values. > -> owner: A UserPrincipal with the name of System.getProperty("user.name") if property access is allowed, "" otherwise > -> group: A GroupPrincipal with the name "". > -> permissions: Set.of(OWNER_READ, OWNER_WRITE, GROUP_READ) > > The default values can be modified by using the properties "defaultOwner", "defaultGroup" and "defaultPermissions". > > Implementation wise the ZipFileAttributeView always extends PosixFileAttributeView but behaves different, depending on how it was obtained. > > Within ZipFileSystem, the Entry inner class is not static any more but always has a reference to the Enclosing ZipFileSystem. That's needed because default owner/group/permission can be set on ZipFileSystem instance level now and the Entry, implementing the FileAttributes needs to know where it belongs to. This seems somewhat logical anyway. > > The new test "TestPosix" is quite extensive. I had to add 2 permissions to test.policy to allow testing in a restricted environment. > > Module-info and CSR have been adopted, too. > > Thanks in advance for reviewing. > > Best regards > Christoph > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Montag, 21. Januar 2019 10:17 >> To: 'Alan Bateman' >> Cc: nio-dev ; OpenJDK Dev list > dev at openjdk.java.net>; Java Core Libs ; >> Volker Simonis >> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions >> >> Hi Alan, >> >> first of all, thank you for your input on this. >> >>> I think the approach to explore are: >>> >>> 1. zipfs supports PosixFileAttributeView without subsetting. If >>> readAttribute(file, BasicFileAttributes.class) succeeds then >>> readAttribute(file, PosixFileAttributes.class) should also succeed, even >>> if there aren't permissions encoded in the zip entry's external file >>> attributes. It would mean that owner and group return default values, >>> and permissions may return a default value. It does mean you can't >>> distinguish the default value from "no permissions" but there is >>> precedence for that, e.g. mount a FAT32 file system on Linux or Unix >>> systems and `stat` a file to have the stat structure populated with >>> default uid, gid and mode bits. >> >> OK, I can see the point that in a PosixFileAttributeView as it is, there's no >> place for optionality/null values. However, with this approach the benefits >> would be that Files::get/setPosixPermissions would work and that's why I >> think we should pursue this. The challenge will be to find reasonable >> defaults. >> >>> 2. zipfs defines a new FileAttributeView that defines read and write >>> access to permissions stored in a zip entry's external file attribute. >>> As it's a new view then it can define the behavior for the case that the >>> zip entry doesn't have permissions. Furthermore it does not need to >>> extend BasicFileAttributeView so doesn't need to be concerned with bulk >>> access, nor concerned with group/owner. As you know, the attributes API >>> allows for both type safe and dynamic access so you have a choice as to >>> whether to support both or just dynamic access. With the first then >>> jdk.zipfs would export a package with a public interface that defines >>> the view. If someone wants type safe access to the permissions attribute >>> then you need to import the class. The alternative is to not export any >>> packages but just define the view in the module-info. The view its name >>> and define the name/type of the permissions attribute, it will also >>> define how it behaves when the external attributes aren't populated. In >>> usage terms it means reading the permissions will be something like >>> Files.readAttribute(file, "zip:permissions") and casting the value to >>> Set - not pretty but it avoids depending on a >>> JDK-specific API. >> >> For this approach, there are 2 things I dislike. The first is that I don't think we >> should export named packages from module jdk.zipfs that people would >> develop Java code against while not being in the Java API. And secondly, this >> way would not support using Files::set/getPosixPermissions since the >> specification/implementation of that utility method explicitly refers to >> PosixFileAttributeView. >> >> I can imagine something like this: >> Zipfs by default implements an own view that offers dynamic, not type safe >> access to "zip:permissions" and we'll document this. If a user of zipfs wants >> to see full PosixFileAttributeView support with default values, then we >> should allow for a creation attribute for the zipfs that can control this. Maybe >> we can even allow specifying default values for user, group and permissions >> via zipfs attributes. >> >> I'll work to develop the patch into this direction unless you tell me that this >> idea is bogus (if so, then I hope it be soon ??) >> >> Thanks >> Christoph >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From brian.burkhalter at oracle.com Wed Feb 13 22:15:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 13 Feb 2019 14:15:30 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> Message-ID: > On Feb 13, 2019, at 12:04 PM, Alan Bateman wrote: > > On 13/02/2019 01:36, Brian Burkhalter wrote: >> : >> >> I have revised the specifications of exceptions for the five methods in question and updated the tests accordingly: >> >> http://cr.openjdk.java.net/~bpb/5029431/webrev.02/ >> >> I have not yet updated the wording of the Buffer*flowException classes to remove the restriction to relative operations. I can do that once the rest looks good. >> > I spent a bit of time going through the existing spec to get the various exception cases into my head. I think my concerns and suggestion to keep this consistent with the relative bulk get/set methods were incorrect and that IOOBE is actually the right exception. The methods that I think settle this debate is the absolute get/put methods defined by ByteBuffer for reading/writing primitive values. As an example getLong(index) throws IOOBE if the index is not smaller than the limit minus seven. Sorry for wasting your time on Buffer*flowException, they only come into the picture for methods that need to change the position. I changed all the conditions which would have provoked a Buffer*flowException back to IOOBEs: http://cr.openjdk.java.net/~bpb/5029431/webrev.03/ The reverted work to put the Buffer*flowExceptions in was not a waste time as it resulted in some verbiage improvements as well as locating and correcting one or two incidental javadoc errors elsewhere. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Feb 13 22:26:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Feb 2019 22:26:02 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: <21cfb27e67514b26a4505c589adf2781@sap.com> Hi Alan, thanks for taking a first look into this new edition. > I think the javadoc changes will need a few iterations but we can get to > that once some of the finer details are sorted out. For example, "Posix > Support" isn't quite right as this is about optional support for the > POSIX view of file attributes rather than complete support for POSIX. Ok. > Also the "Zip" view of file attributes will need to be fleshed out more > (the view name for example). I don't know if that's really necessary as the "Zip" view currently is internal to jdk.zips and I don't propose to export it. > I'm not sure about using ${user.name} and "" as default. > Have you looked at using the zip file owner/group (or owner/owner on > Windows) as the default?? Hm, I guess for Unix that'd be ok. But how would I get to the owner of a file in Window's default file system? > Also just wondering if 777 might be more > appropriate (maybe you have a reason for choosing 660?). It might be > useful to see what Linux, macOS and other operating systems do when > mounting a FAT file system. I implemented 640, but it was just chosen without much thinking. I can agree to 777. > Did you consider using the string representation of the user, group and > permissions in the configuration properties? The zip file system > provider could support both of course. String might make it a bit easier > to create the map of configuration properties when creating the file > system e.g > Map.of("enablePosixPermissions", "true", "defaultOwner", "joe", > "defaultPermissions", "rw-rw---"); Sounds like a good and feasible idea. I'll try to address these points in a next iteration. Best regards Christoph From christoph.langer at sap.com Wed Feb 13 22:30:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Feb 2019 22:30:45 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: <818ca9a7fe2445638dddc2481f95f9f8@sap.com> Hi Lance, thanks for looking. > Just starting to take a peek at this and noticed one quick thing in your test: > ------------ > Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") > ?????? > > You do not need the test.dir property ?or the permission added to test.policy > to access it, ?just reference the jar and it will be created in user.dir which is > also writable. Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that? Thanks Christoph From lance.andersen at oracle.com Wed Feb 13 22:53:15 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Feb 2019 17:53:15 -0500 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <818ca9a7fe2445638dddc2481f95f9f8@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <818ca9a7fe2445638dddc2481f95f9f8@sap.com> Message-ID: <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com> Hi Christoph > On Feb 13, 2019, at 5:30 PM, Langer, Christoph wrote: > > Hi Lance, > > thanks for looking. > >> Just starting to take a peek at this and noticed one quick thing in your test: >> ------------ >> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") >> ?????? >> >> You do not need the test.dir property or the permission added to test.policy >> to access it, just reference the jar and it will be created in user.dir which is >> also writable. > > Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that? user.dir points to the scratch directory that test uses, so it is where you want to create the tests. Workspaces can sometimes be read only: For example: ?????? @Test public void test000() throws IOException { System.out.println("test.dir = " + System.getProperty("test.dir", ".")); System.out.println("user.dir = " + System.getProperty("user.dir", ".")); System.out.println( Paths.get(System.getProperty("test.dir", "."), "basic.jar").toAbsolutePath() ); } ----------------- Results in: -------------------- test.dir = . user.dir = /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/./basic.jar Please see http://openjdk.java.net/jtreg/tag-spec.html for the system properties. I do not see test.dir there. ????????? I would just do: ????????? Path foo = Path.of("test.zip"); System.out.println("test.zip path=" + foo.toAbsolutePath()); -------------------------- which results in the output: test.zip path=/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/test.zip Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Feb 14 07:54:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 14 Feb 2019 07:54:16 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <818ca9a7fe2445638dddc2481f95f9f8@sap.com> <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com> Message-ID: Hi Lance, thanks for the detailed explanation, sounds great. I?ll work that in in my next edition ?? Best regards Christoph From: Lance Andersen Sent: Mittwoch, 13. Februar 2019 23:53 To: Langer, Christoph Cc: Alan Bateman ; nio-dev ; Java Core Libs ; OpenJDK Dev list ; Volker Simonis Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions Hi Christoph On Feb 13, 2019, at 5:30 PM, Langer, Christoph > wrote: Hi Lance, thanks for looking. Just starting to take a peek at this and noticed one quick thing in your test: ------------ Paths.get(System.getProperty("test.dir", "."), "testPosix.zip") ?????? You do not need the test.dir property or the permission added to test.policy to access it, just reference the jar and it will be created in user.dir which is also writable. Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that? user.dir points to the scratch directory that test uses, so it is where you want to create the tests. Workspaces can sometimes be read only: For example: ?????? @Test public void test000() throws IOException { System.out.println("test.dir = " + System.getProperty("test.dir", ".")); System.out.println("user.dir = " + System.getProperty("user.dir", ".")); System.out.println( Paths.get(System.getProperty("test.dir", "."), "basic.jar").toAbsolutePath() ); } ----------------- Results in: -------------------- test.dir = . user.dir = /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/./basic.jar Please see http://openjdk.java.net/jtreg/tag-spec.html for the system properties. I do not see test.dir there. ????????? I would just do: ????????? Path foo = Path.of("test.zip"); System.out.println("test.zip path=" + foo.toAbsolutePath()); -------------------------- which results in the output: test.zip path=/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/test.zip Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Feb 14 11:04:32 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Feb 2019 11:04:32 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> Message-ID: <8530D283-B659-4A69-87CE-F35CB9811BBC@oracle.com> > On 13 Feb 2019, at 22:15, Brian Burkhalter wrote: > > >> On Feb 13, 2019, at 12:04 PM, Alan Bateman > wrote: >>> ... >> I spent a bit of time going through the existing spec to get the various exception cases into my head. I think my concerns and suggestion to keep this consistent with the relative bulk get/set methods were incorrect and that IOOBE is actually the right exception. The methods that I think settle this debate is the absolute get/put methods defined by ByteBuffer for reading/writing primitive values. As an example getLong(index) throws IOOBE if the index is not smaller than the limit minus seven. Sorry for wasting your time on Buffer*flowException, they only come into the picture for methods that need to change the position. It is certainly interesting to compare the exceptional behaviour of these new absolute bulk methods to the existing absolute primitive methods of ByteBuffer. I hadn't considered that. Somewhat because I consider the new absolute bulk methods more closely aligned with the relative bulk methods, but mostly because the primitive getter/setters are ByteBuffer specific, while these new absolute bulk methods are across all buffer types. My preference is still for the previous webrev ( .02 ), for the reasons stated above. But since I appear to be in the minority now, and otherwise the changes are good ( and most welcome ), I don't object to webrev .03. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 14 12:05:32 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 12:05:32 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <8530D283-B659-4A69-87CE-F35CB9811BBC@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <8530D283-B659-4A69-87CE-F35CB9811BBC@oracle.com> Message-ID: On 14/02/2019 11:04, Chris Hegarty wrote: > > It is certainly interesting to compare the exceptional behaviour of > these new absolute bulk methods to the existing absolute primitive > methods of ByteBuffer. I hadn't considered that. Somewhat because I > consider the new absolute bulk methods more closely aligned with the > relative bulk methods, but mostly because the primitive getter/setters > are ByteBuffer specific, while these new absolute bulk methods are > across all buffer types. The other observation is that buffer overflow/underflow can only occur with methods that adjust the buffer position. It might be beneficial to put something to that effect in the descriptions of these exceptions (if only to help future maintainers that might have to go through this same exercise). -Alan From chris.hegarty at oracle.com Thu Feb 14 12:59:54 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Feb 2019 12:59:54 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <8530D283-B659-4A69-87CE-F35CB9811BBC@oracle.com> Message-ID: <980BE445-6F52-439B-A51F-EE9318B01776@oracle.com> > On 14 Feb 2019, at 12:05, Alan Bateman wrote: >> > The other observation is that buffer overflow/underflow can only occur with methods that adjust the buffer position. It might be beneficial to put something to that effect in the descriptions of these exceptions It is already there, the exception's class-description says "... relative get/put operation ...", and relative operations are specified to increment the buffer's position. What we are/were discussing is/was possibly removing this relative-only operations restriction. All current usage that I can find has no regard to whether, or not, there is adjustment to the position. The only factors regarding the raising of the exception are the current position, the limit, and the given, or implicit, length argument. -Chris. From Alan.Bateman at oracle.com Thu Feb 14 13:25:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 13:25:49 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> Message-ID: On 13/02/2019 22:15, Brian Burkhalter wrote: > > I changed all the conditions which would have provoked a > Buffer*flowException back to IOOBEs: > > http://cr.openjdk.java.net/~bpb/5029431/webrev.03/ > > The reverted work to put the Buffer*flowExceptions in was not a waste > time as it resulted in some verbiage improvements as well as locating > and correcting one or two incidental javadoc errors elsewhere. > The 4 methods to do bulk transfers to/from arrays looks good. [ Still mulling on put(index, src, srcIndex, length), partly as it's not clear if put(index, src) should be added at the same time ] -Alan From Alan.Bateman at oracle.com Thu Feb 14 13:41:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 13:41:05 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <21cfb27e67514b26a4505c589adf2781@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <21cfb27e67514b26a4505c589adf2781@sap.com> Message-ID: <5397dcad-bc93-618f-6a30-c3b1227b2b9e@oracle.com> On 13/02/2019 22:26, Langer, Christoph wrote: > : >> Also the "Zip" view of file attributes will need to be fleshed out more >> (the view name for example). > I don't know if that's really necessary as the "Zip" view currently is internal to jdk.zips and I don't propose to export it. Not exporting it is fine but are you planning to document "zip:storedPermissions"? The version I looked at did document "storedPermissions" which amounts to zipfs documenting an interface. > >> I'm not sure about using ${user.name} and "" as default. >> Have you looked at using the zip file owner/group (or owner/owner on >> Windows) as the default? > Hm, I guess for Unix that'd be ok. But how would I get to the owner of a file in Window's default file system? The zip provider can use Files.getOwner and that can be used for group when PosixFileAttributeView isn't supported by the file system containing the zip file. > : > I'll try to address these points in a next iteration. Great, I think the finial line on this feature isn't too far away. -Alan From brian.burkhalter at oracle.com Thu Feb 14 15:48:49 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Feb 2019 07:48:49 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> Message-ID: > On Feb 14, 2019, at 5:25 AM, Alan Bateman wrote: > > [ Still mulling on put(index, src, srcIndex, length), partly as it's not clear if put(index, src) should be added at the same time ] The problem I have with put(index,src) is that this would imply updating the position of ?src? do we?d be mixing absolute and relative operations. It would also complicate the ?src? == ?this? situation. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 14 16:15:09 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Feb 2019 08:15:09 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> Message-ID: > On Feb 14, 2019, at 7:48 AM, Brian Burkhalter wrote: > >> On Feb 14, 2019, at 5:25 AM, Alan Bateman > wrote: >> >> [ Still mulling on put(index, src, srcIndex, length), partly as it's not clear if put(index, src) should be added at the same time ] > > The problem I have with put(index,src) is that this would imply updating the position of ?src? do we?d be mixing absolute and relative operations. It would also complicate the ?src? == ?this? situation. Barring objections to the contrary, I think I will file a separate issue to investigate adding put(index,src) and/or put(index,src,srcIndex,length) at a later date and constrain the present issue to the methods to do bulk transfers to/from arrays. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 14 16:25:35 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Feb 2019 08:25:35 -0800 Subject: 8048192: (bf) Out of direct buffer memory message should include the limits Message-ID: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8048192 One possible solution is given below but I am not sure whether composing such an error string is desirable during bootstrap / startup. If this is undesirable then perhaps the issue should be resolved as WNF? Thanks, Brian --- a/src/java.base/share/classes/java/nio/Bits.java +++ b/src/java.base/share/classes/java/nio/Bits.java @@ -172,7 +172,11 @@ } // no luck - throw new OutOfMemoryError("Direct buffer memory"); + throw new OutOfMemoryError + ("Direct buffer memory: MAX_MEMORY = " + MAX_MEMORY + + ", RESERVED_MEMORY = " + RESERVED_MEMORY.get() + + ", TOTAL_CAPACITY = " + TOTAL_CAPACITY.get() + + ", size = " + size + ", cap = " + cap); } finally { -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 14 20:17:46 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Feb 2019 12:17:46 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> Message-ID: <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> > On Feb 14, 2019, at 8:15 AM, Brian Burkhalter wrote: > >> On Feb 14, 2019, at 7:48 AM, Brian Burkhalter > wrote: >> >>> On Feb 14, 2019, at 5:25 AM, Alan Bateman > wrote: >>> >>> [ Still mulling on put(index, src, srcIndex, length), partly as it's not clear if put(index, src) should be added at the same time ] >> >> The problem I have with put(index,src) is that this would imply updating the position of ?src? do we?d be mixing absolute and relative operations. It would also complicate the ?src? == ?this? situation. > > Barring objections to the contrary, I think I will file a separate issue to investigate adding put(index,src) and/or put(index,src,srcIndex,length) at a later date and constrain the present issue to the methods to do bulk transfers to/from arrays. Here is an updated version which removes the absolute put() method which accepts a source buffer: http://cr.openjdk.java.net/~bpb/5029431/webrev.04/ This version uses IOOBEs and not Buffer*flowExceptions for the cases where the supplied parameters would provoke an out of range access. Once we have consensus on this I will update the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8212619 . I created a separate issue to track the potential effort to reinstate the removed method later: https://bugs.openjdk.java.net/browse/JDK-8219014 Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 14 20:49:32 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 20:49:32 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> Message-ID: On 14/02/2019 20:17, Brian Burkhalter wrote: > > Here is an updated version which removes the absolute put() method > which accepts a source buffer: > > http://cr.openjdk.java.net/~bpb/5029431/webrev.04/ > > This version uses IOOBEs and not Buffer*flowExceptions for the cases > where the supplied parameters would provoke an out of range access. > Once we have consensus on this I will update the corresponding CSR > https://bugs.openjdk.java.net/browse/JDK-8212619. > This plan, and javadoc, looks good to me. > I created a separate issue to track the potential effort to reinstate > the removed method later: > > https://bugs.openjdk.java.net/browse/JDK-8219014 > Splitting this one out seems okay with me too. -Alan From brian.burkhalter at oracle.com Thu Feb 14 22:36:15 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Feb 2019 14:36:15 -0800 Subject: 8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position Message-ID: <23196D55-A907-4242-ADF6-222A099C145C@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8065262 One possibility would be to update the class level specification as To clear this up, perhaps a sentence could merely be added to the specification of CharBuffer in X-Buffer.java.template: #if[char] * *

This class implements the {@link CharSequence} interface so that * character buffers may be used wherever character sequences are accepted, for * example in the regular-expression package {@link java.util.regex}. + * {@code CharSequence} methods operate relative to the current position of + * the buffer when they are invoked. *

* #end[char] An alternative, given that chars() is overridden in CharBuffer, would be to copy its specification with the addition of verbiage indicating that the IntStream starts from the current position. The same problem would however remain for CharSequence.codePoints(). Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 15 00:42:02 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Feb 2019 16:42:02 -0800 Subject: 8218418: (fs) Files.createSymbolicLink should use SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (win) Message-ID: <1F64D02D-DFE9-4479-A979-C3D1375E9A42@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8218418 The proposed change below ran without error through the jdk_core tests on Windows. Presumably it is covered sufficiently by test/jdk/java/nio/file/Files/Links.java so the issue could be labelled noreg-other. Thanks, Brian --- a/src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c +++ b/src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c @@ -1063,8 +1063,14 @@ LPCWSTR link = jlong_to_ptr(linkAddress); LPCWSTR target = jlong_to_ptr(targetAddress); - /* On Windows 64-bit this appears to succeed even when there is insufficient privileges */ - if (CreateSymbolicLinkW(link, target, (DWORD)flags) == 0) + // Allow creation of symbolic links when the process is not elevated. + // Developer Mode must be enabled for this option to function, otherwise + // it will be ignored. + DWORD dwFlags = (DWORD)flags | SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE; + + // On Windows 64-bit this appears to succeed even when there are + // insufficient privileges + if (CreateSymbolicLinkW(link, target, dwFlags) == 0) throwWindowsException(env, GetLastError()); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 15 08:24:38 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2019 08:24:38 +0000 Subject: 8218418: (fs) Files.createSymbolicLink should use SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (win) In-Reply-To: <1F64D02D-DFE9-4479-A979-C3D1375E9A42@oracle.com> References: <1F64D02D-DFE9-4479-A979-C3D1375E9A42@oracle.com> Message-ID: <4130f5d7-60d6-532e-f5bc-6a58769bf1f0@oracle.com> On 15/02/2019 00:42, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8218418 > > The proposed change below ran without error through the jdk_core tests > on Windows. Presumably it is covered sufficiently by > test/jdk/java/nio/file/Files/Links.java so the issue could be labelled > noreg-other. I think the fix looks okay but I think it needs checking in the different configurations (process has the privilege, does not have the privilege, and "developer mode") to be sure. This isn't something we can setup in the jtreg tests. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 15 09:06:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2019 09:06:54 +0000 Subject: 8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position In-Reply-To: <23196D55-A907-4242-ADF6-222A099C145C@oracle.com> References: <23196D55-A907-4242-ADF6-222A099C145C@oracle.com> Message-ID: On 14/02/2019 22:36, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8065262 > > One possibility would be to update the class level specification as > > To clear this up, perhaps a sentence could merely be added to the > specification of CharBuffer in X-Buffer.java.template: > > #if[char] > ?* > ??*

This class implements the {@link CharSequence} interface so that > ??* character buffers may be used wherever character sequences are > accepted, for > ??* example in the regular-expression package {@link java.util.regex}. > + * {@code CharSequence} methods operate relative to the current > position of > + * the buffer when they are invoked. > ??*

> ?* > #end[char] > I agree that adding a statement class description will help (and avoid bug reports like this). Your looks okay and is consistent with the wording in the method description. A small suggestion is to start with "The methods defined by CharSequence ...". -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 15 16:10:31 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Feb 2019 08:10:31 -0800 Subject: 8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position In-Reply-To: References: <23196D55-A907-4242-ADF6-222A099C145C@oracle.com> Message-ID: <9262CFEB-B016-4BE8-84DF-4E5D1949B8F2@oracle.com> > On Feb 15, 2019, at 1:06 AM, Alan Bateman wrote: > > On 14/02/2019 22:36, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8065262 >> >> One possibility would be to update the class level specification as >> >> To clear this up, perhaps a sentence could merely be added to the specification of CharBuffer in X-Buffer.java.template: >> >> #if[char] >> * >> *

This class implements the {@link CharSequence} interface so that >> * character buffers may be used wherever character sequences are accepted, for >> * example in the regular-expression package {@link java.util.regex}. >> + * {@code CharSequence} methods operate relative to the current position of >> + * the buffer when they are invoked. >> *

>> * >> #end[char] >> > I agree that adding a statement class description will help (and avoid bug reports like this). Your looks okay and is consistent with the wording in the method description. A small suggestion is to start with "The methods defined by CharSequence ...". All right, I?ll update the wording per your suggestion and file a CSR. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 15 16:26:19 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Feb 2019 08:26:19 -0800 Subject: 8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position In-Reply-To: <9262CFEB-B016-4BE8-84DF-4E5D1949B8F2@oracle.com> References: <23196D55-A907-4242-ADF6-222A099C145C@oracle.com> <9262CFEB-B016-4BE8-84DF-4E5D1949B8F2@oracle.com> Message-ID: > On Feb 15, 2019, at 8:10 AM, Brian Burkhalter wrote: > >> I agree that adding a statement class description will help (and avoid bug reports like this). Your looks okay and is consistent with the wording in the method description. A small suggestion is to start with "The methods defined by CharSequence ...". > > All right, I?ll update the wording per your suggestion and file a CSR. CSR filed: https://bugs.openjdk.java.net/browse/JDK-8219118 Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Fri Feb 15 16:32:49 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 15 Feb 2019 11:32:49 -0500 Subject: 8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position In-Reply-To: References: <23196D55-A907-4242-ADF6-222A099C145C@oracle.com> <9262CFEB-B016-4BE8-84DF-4E5D1949B8F2@oracle.com> Message-ID: Hi Brian, Looks good; A tip for the summary sentence is to write it so it stands completely independent of the rest of the CSR. It gets used in other contexts and in lists of changes. Thanks, Roger On 02/15/2019 11:26 AM, Brian Burkhalter wrote: > >> On Feb 15, 2019, at 8:10 AM, Brian Burkhalter >> > wrote: >> >>> I agree that adding a statement class description will help (and >>> avoid bug reports like this). Your looks okay and is consistent with >>> the wording in the method description. A small suggestion is to >>> start with "The methods defined by CharSequence ...". >> >> All right, I?ll update the wording per your suggestion and file a CSR. > > CSR filed: https://bugs.openjdk.java.net/browse/JDK-8219118 > > Brian From brian.burkhalter at oracle.com Fri Feb 15 16:37:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Feb 2019 08:37:08 -0800 Subject: 8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position In-Reply-To: References: <23196D55-A907-4242-ADF6-222A099C145C@oracle.com> <9262CFEB-B016-4BE8-84DF-4E5D1949B8F2@oracle.com> Message-ID: Hi Roger, Thanks for the review, suggestion, and emendation. Brian > On Feb 15, 2019, at 8:32 AM, Roger Riggs wrote: > > Looks good; > A tip for the summary sentence is to write it so it stands completely independent of the rest of the CSR. > It gets used in other contexts and in lists of changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 19 16:29:11 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Feb 2019 08:29:11 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <971066D2-3062-46C3-8E7B-B22A717B85AB@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> <971066D2-3062-46C3-8E7B-B22A717B85AB@oracle.com> Message-ID: > On Feb 14, 2019, at 5:46 PM, Brian Burkhalter wrote: > >> On Feb 14, 2019, at 12:49 PM, Alan Bateman > wrote: >> >>> Once we have consensus on this I will update the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8212619 . >>> >> This plan, and javadoc, looks good to me. > > I have updated the CSR accordingly in case anyone would like to review it. The CSR was approved so the specification is complete. Does anyone have any further review comments on the implementation and/or test coverage before I check in this work? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 19 20:08:29 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Feb 2019 20:08:29 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> <971066D2-3062-46C3-8E7B-B22A717B85AB@oracle.com> Message-ID: On 19/02/2019 16:29, Brian Burkhalter wrote: > > The CSR was approved so the specification is complete. Does anyone > have any further review comments on the implementation and/or test > coverage before I check in this work? > The implementation looks good. One thing to check on test coverage is CharBuffers that are created by wrapping Strings and other char sequences (we have a history of missing that in test cases). -Alan From brian.burkhalter at oracle.com Tue Feb 19 20:32:11 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Feb 2019 12:32:11 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> <971066D2-3062-46C3-8E7B-B22A717B85AB@oracle.com> Message-ID: <9A18FD57-34D2-4E02-A83C-3B9DE3C3AEB5@oracle.com> > On Feb 19, 2019, at 12:08 PM, Alan Bateman wrote: > > On 19/02/2019 16:29, Brian Burkhalter wrote: >> >> The CSR was approved so the specification is complete. Does anyone have any further review comments on the implementation and/or test coverage before I check in this work? >> > The implementation looks good. One thing to check on test coverage is CharBuffers that are created by wrapping Strings and other char sequences (we have a history of missing that in test cases). OK, I will double check that. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Tue Feb 19 20:54:20 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 19 Feb 2019 15:54:20 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods Message-ID: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> Hi all, Please review the update to Filesystems which adds the methods: newFileSystem(Path, Map) and newFileSystem(Path, Map, ClassLoader). These methods are being added to provide better support for working with the Zip File System. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8218875/webrev.00/index.html Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From roger.riggs at oracle.com Tue Feb 19 21:15:18 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 19 Feb 2019 16:15:18 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> Message-ID: Hi Lance, Did you consider alternative method names or signatures that would avoid the ambiguity and the necessity of ugly/hacky casts of (ClassLoader)null)? Perhaps adding a method that has only Path and assumes a null classloader? ? newFileSystem(Path). ??, Roger On 2/19/19 3:54 PM, Lance Andersen wrote: > Hi all, > > Please review the update to Filesystems which adds ?the methods: > > ?newFileSystem(Path, Map) and?newFileSystem(Path, > Map, ClassLoader). > > These methods are being added to provide better support for working > with ?the Zip File System. > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8218875/webrev.00/index.html > > Best > Lance > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From brian.burkhalter at oracle.com Tue Feb 19 22:29:48 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Feb 2019 14:29:48 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <9A18FD57-34D2-4E02-A83C-3B9DE3C3AEB5@oracle.com> References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <7EDCFF5E-9EF4-4AE3-837B-95FBE20B7749@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> <971066D2-3062-46C3-8E7B-B22A717B85AB@oracle.com> <9A18FD57-34D2-4E02-A83C-3B9DE3C3AEB5@oracle.com> Message-ID: > On Feb 19, 2019, at 12:32 PM, Brian Burkhalter wrote: > >> One thing to check on test coverage is CharBuffers that are created by wrapping Strings and other char sequences (we have a history of missing that in test cases). > > OK, I will double check that. I added lines 963-969 to Basic-X.java.template to test absolute get() from a CharBuffer created by wrapping a string; webrev updated in place [1]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/5029431/webrev.04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 20 01:20:57 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Feb 2019 17:20:57 -0800 Subject: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced Message-ID: <0C5F8BB5-D647-48F2-B093-EBF5C537F553@oracle.com> https://bugs.openjdk.java.net/browse/JDK-4833719 Provide covariant return type overrides for asReadOnlyBuffer(), compact(), duplicate(), and slice() [1]. If desirable, such overrides could also be provided for the bulk get() methods and the put*() methods. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/4833719/webrev.00/ From Alan.Bateman at oracle.com Wed Feb 20 06:37:59 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 06:37:59 +0000 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> <971066D2-3062-46C3-8E7B-B22A717B85AB@oracle.com> <9A18FD57-34D2-4E02-A83C-3B9DE3C3AEB5@oracle.com> Message-ID: On 19/02/2019 22:29, Brian Burkhalter wrote: >> On Feb 19, 2019, at 12:32 PM, Brian Burkhalter >> > wrote: >> >>> One thing to check on test coverage is CharBuffers that are created >>> by wrapping Strings and other char sequences (we have a history of >>> missing that in test cases). >> >> OK, I will double check that. > > I added lines 963-969 to Basic-X.java.template to test absolute get() > from a CharBuffer created by wrapping a string; webrev updated in > place [1]. > Thanks. Looks good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Feb 20 07:00:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 07:00:17 +0000 Subject: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced In-Reply-To: <0C5F8BB5-D647-48F2-B093-EBF5C537F553@oracle.com> References: <0C5F8BB5-D647-48F2-B093-EBF5C537F553@oracle.com> Message-ID: On 20/02/2019 01:20, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-4833719 > > Provide covariant return type overrides for asReadOnlyBuffer(), compact(), duplicate(), and slice() [1]. If desirable, such overrides could also be provided for the bulk get() methods and the put*() methods. > I don't have cycles to think about this one right now but I suspect this will require study to figure out if spec changes are needed. For example, we might have to clarify how force and loader should behave when invoked on a MBB that is a view or the result of a slice or duplicate. -Alan From christoph.langer at sap.com Wed Feb 20 10:23:23 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Feb 2019 10:23:23 +0000 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> Message-ID: <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Hi Lance, first of all, thanks for taking this. I also lately wondered about why there wasn?t the same set of newFileSystem methods in FileSystems that would take a Path compared to those that work on a URI. I was about to ask this on the mailing list. It?s really too bad that there is this method with signature newFileSystem?(Path path, ClassLoader loader) when it rather should have been newFileSystem?(Path path, Map env, ClassLoader loader) to mirror the API using the URI. I think we should not become source incompatible. So what about spending a set of 3 methods that are named FileSystems::of that take a Path? And in any case, deprecate ?newFileSystem?(Path path, ClassLoader loader)?. I assume you?ll open a CSR for that change once it?s a bit clearer on where we?re going with it? Thanks Christoph From: nio-dev On Behalf Of Roger Riggs Sent: Dienstag, 19. Februar 2019 22:15 To: nio-dev at openjdk.java.net Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods Hi Lance, Did you consider alternative method names or signatures that would avoid the ambiguity and the necessity of ugly/hacky casts of (ClassLoader)null)? Perhaps adding a method that has only Path and assumes a null classloader? newFileSystem(Path). ??, Roger On 2/19/19 3:54 PM, Lance Andersen wrote: Hi all, Please review the update to Filesystems which adds the methods: newFileSystem(Path, Map) and newFileSystem(Path, Map, ClassLoader). These methods are being added to provide better support for working with the Zip File System. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8218875/webrev.00/index.html Best Lance [cid:image001.gif at 01D4C90D.BE12FBE0] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From Alan.Bateman at oracle.com Wed Feb 20 10:35:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 10:35:27 +0000 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <9f9975a1c3bd47898d15cdeef75a5060@sap.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Message-ID: <4f061987-7b77-7cbb-fcce-34966dc92d1b@oracle.com> On 20/02/2019 10:23, Langer, Christoph wrote: > : > > I think we should not become source incompatible. So what about > spending a set of 3 methods that are named FileSystems::of that take a > Path? And in any case, deprecate ?newFileSystem?(Path path, > ClassLoader loader)?. > > The source incompatibility issue is really minor but I know Lance is exploring that. Adding new static factory methods named `of` is an idea worth exploring though. The newFileSystem?(Path path, ClassLoader loader) is not toxic, it doesn't need to be deprecated because of new overloads or alternative static factory methods. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Feb 20 10:53:14 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 10:53:14 +0000 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <9f9975a1c3bd47898d15cdeef75a5060@sap.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Message-ID: <91146a1c-92b2-8af5-1180-ccdc49742ba7@oracle.com> On 20/02/2019 10:23, Langer, Christoph wrote: > > It?s really too bad that there is this method with signature > newFileSystem?(Path path, ClassLoader loader) when it rather should > have been newFileSystem?(Path path, Map env, ClassLoader > loader) to mirror the API using the URI. > > Just on this point, the 2-arg method is useful to open a file as a file system without knowing anything about its format. To use the 3-arg version with anything other than an empty Map means having configuration about the file system. There is room for both usages. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Feb 20 10:53:35 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 20 Feb 2019 10:53:35 +0000 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> Message-ID: <8e89faf2-f9a5-490b-045f-da60e54f8bff@oracle.com> Hi Lance, FileSystems.java: 481 public static FileSystem newFileSystem(Path path, Map env, 482 ClassLoader loader) 483 throws IOException 484 { The javadoc says that env may be empty - which implies it shouldn't be null. I'd suggest adding an explicit null check here rather than leaving it up to the provider. I'd also suggest to make a defensive copy of the env Map, e.g. using Map.copyOf, before passing it to any provider. We don't want provider's code to start depending on any particular implementation of Map. best regards, -- daniel On 19/02/2019 20:54, Lance Andersen wrote: > Hi all, > > Please review the update to Filesystems which adds ?the methods: > > ?newFileSystem(Path, Map) and?newFileSystem(Path, > Map, ClassLoader). > > These methods are being added to provide better support for working with > ?the Zip File System. > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8218875/webrev.00/index.html > > Best > Lance > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Wed Feb 20 11:50:05 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Feb 2019 06:50:05 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <9f9975a1c3bd47898d15cdeef75a5060@sap.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Message-ID: <0E4A4EF0-58BA-496E-BD70-E3A631F01CCE@oracle.com> Hi Roger, thank you for your review.. > > From: nio-dev > On Behalf Of Roger Riggs > Sent: Dienstag, 19. Februar 2019 22:15 > To: nio-dev at openjdk.java.net > Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods > > Hi Lance, > > Did you consider alternative method names or signatures that would avoid > the ambiguity and the necessity of ugly/hacky casts of (ClassLoader)null)? > I did consider this and thought of using FileSystems::of. I did not go that way (for now) because I felt if I did this, I needed to do the same for the newFileSystem methods which take URI and seemed excessive I went back and read Effective Java naming conventions and I think I talked myself out of using anything other than newFileSystem Alan and I did exchange email regarding the need for the cast but felt this was a very small edge case and the benefits out-weighed the small compatibility issue. > > Perhaps adding a method that has only Path and assumes a null classloader? > newFileSystem(Path). > I could do this if others feel it is worthwhile. Best Lance > > ??, Roger > > > On 2/19/19 3:54 PM, Lance Andersen wrote: > Hi all, > > Please review the update to Filesystems which adds the methods: > > newFileSystem(Path, Map) and newFileSystem(Path, Map, ClassLoader). > > These methods are being added to provide better support for working with the Zip File System. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8218875/webrev.00/index.html > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From lance.andersen at oracle.com Wed Feb 20 11:54:46 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Feb 2019 06:54:46 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <9f9975a1c3bd47898d15cdeef75a5060@sap.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Message-ID: Hi Christoph, Thank you for the review > On Feb 20, 2019, at 5:23 AM, Langer, Christoph wrote: > > Hi Lance, > > first of all, thanks for taking this. I also lately wondered about why there wasn?t the same set of newFileSystem methods in FileSystems that would take a Path compared to those that work on a URI. I was about to ask this on the mailing list. timing is everything :-) > > It?s really too bad that there is this method with signature newFileSystem?(Path path, ClassLoader loader) when it rather should have been newFileSystem?(Path path, Map env, ClassLoader loader) to mirror the API using the URI. > > I think we should not become source incompatible. So what about spending a set of 3 methods that are named FileSystems::of that take a Path? And in any case, deprecate ?newFileSystem?(Path path, ClassLoader loader)?. > Please see my response to Roger?s similar question. I am not opposed to going with Filesystems::of, just think we would need to do it for all of the existing methods. It seems to add some extra bloat. So I think the question is whether the extra bloat is worth it vs. the small compatibility issue > I assume you?ll open a CSR for that change once it?s a bit clearer on where we?re going with it? Yes, that is the plan > > Thanks > Christoph > > From: nio-dev > On Behalf Of Roger Riggs > Sent: Dienstag, 19. Februar 2019 22:15 > To: nio-dev at openjdk.java.net > Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods > > Hi Lance, > > Did you consider alternative method names or signatures that would avoid > the ambiguity and the necessity of ugly/hacky casts of (ClassLoader)null)? > > Perhaps adding a method that has only Path and assumes a null classloader? > newFileSystem(Path). > > ??, Roger > > > On 2/19/19 3:54 PM, Lance Andersen wrote: > Hi all, > > Please review the update to Filesystems which adds the methods: > > newFileSystem(Path, Map) and newFileSystem(Path, Map, ClassLoader). > > These methods are being added to provide better support for working with the Zip File System. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8218875/webrev.00/index.html > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From lance.andersen at oracle.com Wed Feb 20 11:57:17 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Feb 2019 06:57:17 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <8e89faf2-f9a5-490b-045f-da60e54f8bff@oracle.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <8e89faf2-f9a5-490b-045f-da60e54f8bff@oracle.com> Message-ID: <2ABA8FDA-EADC-44F3-BF9C-136FB04203B5@oracle.com> Hi Daniel, Thank you for the review > On Feb 20, 2019, at 5:53 AM, Daniel Fuchs wrote: > > Hi Lance, > > FileSystems.java: > > 481 public static FileSystem newFileSystem(Path path, Map env, > 482 ClassLoader loader) > 483 throws IOException > 484 { > > The javadoc says that env may be empty - which implies > it shouldn't be null. I'd suggest adding an explicit null > check here rather than leaving it up to the provider. I can do that, same needs done for the URI version of this method > > I'd also suggest to make a defensive copy of the env Map, > e.g. using Map.copyOf, before passing it to any provider. > We don't want provider's code to start depending on any > particular implementation of Map. I can also do that and as above, needs done for the URI version of this method Best Lance > > best regards, > > -- daniel > > On 19/02/2019 20:54, Lance Andersen wrote: >> Hi all, >> Please review the update to Filesystems which adds the methods: >> newFileSystem(Path, Map) and newFileSystem(Path, Map, ClassLoader). >> These methods are being added to provide better support for working with the Zip File System. >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8218875/webrev.00/index.html >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From christoph.langer at sap.com Wed Feb 20 13:17:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Feb 2019 13:17:47 +0000 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Message-ID: Hi Lance, > It?s really too bad that there is this method with signature newFileSystem? > (Path path, ClassLoader loader) when it rather should have been > newFileSystem?(Path path, Map env, ClassLoader loader) to mirror > the API using the URI. > > I think we should not become source incompatible. So what about spending > a set of 3 methods that are named FileSystems::of that take a Path? And in > any case, deprecate ?newFileSystem?(Path path, ClassLoader loader)?. > > > Please see my response to Roger?s similar question. > > I am not opposed to ?going with Filesystems::of, just think we would need to > do it for all of the existing methods. ? It seems to add some extra bloat. ?So I > think the question is whether the extra bloat is worth it vs. the small > compatibility issue I can see that... If you think the source compatibility issue is neglectable, then so be it. I won't be devil's advocate there ?? But, in any case, there's one thing I'm missing: Why don't you add a FileSystems.newFileSystem(Path) method? I think that's the method that people want to call usually when they currently call FileSystems.newFileSystem(Path, (ClassLoader)null)... Thanks Christoph From brian.burkhalter at oracle.com Wed Feb 20 15:50:20 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 20 Feb 2019 07:50:20 -0800 Subject: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <55C83CDC-FD0A-4751-8033-67C73F373FA4@oracle.com> <85362f5f-abdb-36b5-ee41-66300303282a@oracle.com> <0d440d5f-c000-a899-d72e-b2f1ddedd76d@oracle.com> <1275A85D-CE3C-47C4-B287-4B719CDDF064@oracle.com> <322F854A-451D-43D7-A541-56CDCE09DB17@oracle.com> <1b83feb4-5028-e462-376d-a09507ab1ebd@oracle.com> <78CAE1D5-5370-48E7-A8E5-1B4821699B97@oracle.com> <971066D2-3062-46C3-8E7B-B22A717B85AB@oracle.com> <9A18FD57-34D2-4E02-A83C-3B9DE3C3AEB5@oracle.com> Message-ID: <1D5F2147-910E-40CC-B294-1E1350C011EF@oracle.com> > On Feb 19, 2019, at 10:37 PM, Alan Bateman wrote: > > On 19/02/2019 22:29, Brian Burkhalter wrote: >>> On Feb 19, 2019, at 12:32 PM, Brian Burkhalter > wrote: >>> >>>> One thing to check on test coverage is CharBuffers that are created by wrapping Strings and other char sequences (we have a history of missing that in test cases). >>> >>> OK, I will double check that. >> >> I added lines 963-969 to Basic-X.java.template to test absolute get() from a CharBuffer created by wrapping a string; webrev updated in place [1]. >> > Thanks. Looks good. I?ll check this in later today. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 20 15:51:43 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 20 Feb 2019 07:51:43 -0800 Subject: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced In-Reply-To: References: <0C5F8BB5-D647-48F2-B093-EBF5C537F553@oracle.com> Message-ID: > On Feb 19, 2019, at 11:00 PM, Alan Bateman wrote: > > On 20/02/2019 01:20, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-4833719 >> >> Provide covariant return type overrides for asReadOnlyBuffer(), compact(), duplicate(), and slice() [1]. If desirable, such overrides could also be provided for the bulk get() methods and the put*() methods. >> > I don't have cycles to think about this one right now but I suspect this will require study to figure out if spec changes are needed. For example, we might have to clarify how force and loader should behave when invoked on a MBB that is a view or the result of a slice or duplicate. Good point. I can investigate. Given the age of this issue it?s not pressing. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Wed Feb 20 16:34:15 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 20 Feb 2019 11:34:15 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Message-ID: <9152f75e-1c8d-2d97-b7ca-178638df9283@oracle.com> +1 On 02/20/2019 08:17 AM, Langer, Christoph wrote: > But, in any case, there's one thing I'm missing: Why don't you add a FileSystems.newFileSystem(Path) method? I think that's the method that people want to call usually when they currently call FileSystems.newFileSystem(Path, (ClassLoader)null)... -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Feb 20 16:41:24 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 16:41:24 +0000 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> Message-ID: <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com> On 20/02/2019 13:17, Langer, Christoph wrote: > : > But, in any case, there's one thing I'm missing: Why don't you add a FileSystems.newFileSystem(Path) method? I think that's the method that people want to call usually when they currently call FileSystems.newFileSystem(Path, (ClassLoader)null)... > I agree that it's worth considering now, if only because zipfs has got a lot of attention. -Alan From lance.andersen at oracle.com Wed Feb 20 18:11:39 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Feb 2019 13:11:39 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com> Message-ID: <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com> > On Feb 20, 2019, at 11:41 AM, Alan Bateman wrote: > > On 20/02/2019 13:17, Langer, Christoph wrote: >> : >> But, in any case, there's one thing I'm missing: Why don't you add a FileSystems.newFileSystem(Path) method? I think that's the method that people want to call usually when they currently call FileSystems.newFileSystem(Path, (ClassLoader)null)... >> > I agree that it's worth considering now, if only because zipfs has got a lot of attention. Ok, http://cr.openjdk.java.net/~lancea/8218875/webrev.01/index.html adds it > > -Alan > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From christoph.langer at sap.com Wed Feb 20 18:32:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Feb 2019 18:32:55 +0000 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com> <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com> Message-ID: <3f19ba19a06a4f539fc3a620e62725a2@sap.com> Good. Now you can go and change all places where you call newFileSystem(Path, (ClassLoader)null) to newFileSystem(Path) ?? From: Lance Andersen Sent: Mittwoch, 20. Februar 2019 19:12 To: Alan Bateman Cc: Langer, Christoph ; nio-dev at openjdk.java.net Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods On Feb 20, 2019, at 11:41 AM, Alan Bateman > wrote: On 20/02/2019 13:17, Langer, Christoph wrote: : But, in any case, there's one thing I'm missing: Why don't you add a FileSystems.newFileSystem(Path) method? I think that's the method that people want to call usually when they currently call FileSystems.newFileSystem(Path, (ClassLoader)null)... I agree that it's worth considering now, if only because zipfs has got a lot of attention. Ok, http://cr.openjdk.java.net/~lancea/8218875/webrev.01/index.html adds it -Alan [cid:image001.gif at 01D4C953.13899800] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From lance.andersen at oracle.com Wed Feb 20 18:46:59 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Feb 2019 13:46:59 -0500 Subject: RFR 8218875: Add new FileSystems.newFileSystem methods In-Reply-To: <3f19ba19a06a4f539fc3a620e62725a2@sap.com> References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com> <9f9975a1c3bd47898d15cdeef75a5060@sap.com> <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com> <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com> <3f19ba19a06a4f539fc3a620e62725a2@sap.com> Message-ID: <4F48CA29-06AA-4776-9966-2CA74C748EC7@oracle.com> > On Feb 20, 2019, at 1:32 PM, Langer, Christoph wrote: > > Good. Now you can go and change all places where you call newFileSystem(Path, (ClassLoader)null) to newFileSystem(Path) ?? Lol. Yes I thought about that, but want to finalize whether we are going with FileSystems::newFileSystem vs FileSystems::of prior to doing that. > > From: Lance Andersen > > Sent: Mittwoch, 20. Februar 2019 19:12 > To: Alan Bateman > > Cc: Langer, Christoph >; nio-dev at openjdk.java.net > Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods > > > On Feb 20, 2019, at 11:41 AM, Alan Bateman > wrote: > > On 20/02/2019 13:17, Langer, Christoph wrote: > > : > But, in any case, there's one thing I'm missing: Why don't you add a FileSystems.newFileSystem(Path) method? I think that's the method that people want to call usually when they currently call FileSystems.newFileSystem(Path, (ClassLoader)null)... > > I agree that it's worth considering now, if only because zipfs has got a lot of attention. > > Ok, http://cr.openjdk.java.net/~lancea/8218875/webrev.01/index.html adds it > > > > -Alan > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From brian.burkhalter at oracle.com Wed Feb 20 22:07:32 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 20 Feb 2019 14:07:32 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char Message-ID: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8011135 With the proposed change [1] applied, the performance of CharBuffer.put(String) was measured [2] to be 5-6X faster than without the change [3]. Thanks, Brian [1] diff --- a/src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template +++ b/src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template @@ -270,6 +270,22 @@ #end[rw] } +#if[char] + + public $Type$Buffer put(String src, int start, int end) { + int length = end - start; + checkBounds(start, length, src.length()); + if (isReadOnly()) + throw new ReadOnlyBufferException(); + if (length > remaining()) + throw new BufferOverflowException(); + src.getChars(start, end, hb, ix(position())); + position(position() + length); + return this; + } + +#end[char] + public $Type$Buffer compact() { [2] benchmark public class PutStringBench { private static final String STR = new String (" abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 "); private static final CharBuffer BUF = CharBuffer.allocate(1024); @Benchmark public CharBuffer putString() { BUF.rewind(); return BUF.put(STR); } } [3] results [a] before Result "com.oracle.PutStringBench.putString": 18764158.739 ?(99.9%) 250376.712 ops/s [Average] (min, avg, max) = (18614233.510, 18764158.739, 19122478.453), stdev = 165608.693 CI (99.9%): [18513782.027, 19014535.452] (assumes normal distribution) Result "com.oracle.PutStringBench.putString": 15920473.709 ?(99.9%) 1212446.652 ops/s [Average] (min, avg, max) = (14842084.221, 15920473.709, 17371424.249), stdev = 801958.390 CI (99.9%): [14708027.056, 17132920.361] (assumes normal distribution) Benchmark Mode Cnt Score Error Units PutStringBench.putString thrpt 5 18571082.538 ? 693010.965 ops/s [b] after Result "com.oracle.PutStringBench.putString": 108696688.710 ?(99.9%) 3774080.561 ops/s [Average] (min, avg, max) = (101907400.750, 108696688.710, 110524934.117), stdev = 2496320.615 CI (99.9%): [104922608.149, 112470769.272] (assumes normal distribution) Result "com.oracle.PutStringBench.putString": 103110531.621 ?(99.9%) 5281599.715 ops/s [Average] (min, avg, max) = (96691960.810, 103110531.621, 106781180.294), stdev = 3493451.195 CI (99.9%): [97828931.906, 108392131.336] (assumes normal distribution) Benchmark Mode Cnt Score Error Units PutStringBench.putString thrpt 5 106026596.397 ? 1375553.439 ops/s -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Thu Feb 21 10:31:04 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 21 Feb 2019 11:31:04 +0100 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> Message-ID: <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> Hi Brian, patch looks good to me, but the new implementation will throw BufferOverflowException before writing anything to the buffer, whereas the old one would fill up the CharBuffer. I'm not sure this change in behavior is acceptable, and it should be straightforward to fix. Benchmark looks OK. I'd parameterize it so you test with a mix from tiny to really long Strings, along with variants that contain higher unicode codepoints for bonus points. Feel free to contribute it under test/micro. Thanks! /Claes On 2019-02-20 23:07, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8011135 > > With the proposed change [1] applied, the performance of > CharBuffer.put(String) was measured [2] to be 5-6X faster than without > the change [3]. > > Thanks, > > Brian > > [1] diff > > --- a/src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template > +++ b/src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template > @@ -270,6 +270,22 @@ > ?#end[rw] > ?? ? } > > > +#if[char] > + > +? ? public $Type$Buffer put(String src, int start, int end) { > +? ? ? ? int length = end - start; > +? ? ? ? checkBounds(start, length, src.length()); > +? ? ? ? if (isReadOnly()) > +? ? ? ? ? ? throw new ReadOnlyBufferException(); > +? ? ? ? if (length > remaining()) > +? ? ? ? ? ? throw new BufferOverflowException(); > +? ? ? ? src.getChars(start, end, hb, ix(position())); > +? ? ? ? position(position() + length); > +? ? ? ? return this; > +? ? } > + > +#end[char] > + > ?? ? public $Type$Buffer compact() { > > > [2] benchmark > > public class PutStringBench { > > ? ? private static final String STR = new String > ? ? ? ? (" > abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 "); > > ? ? private static final CharBuffer BUF = CharBuffer.allocate(1024); > > ? ? @Benchmark > ? ? public CharBuffer putString() { > ? ? ? ? BUF.rewind(); > ? ? ? ? return BUF.put(STR); > ? ? } > > } > > > [3] results > [a] before > > Result "com.oracle.PutStringBench.putString": > ? 18764158.739 ?(99.9%) 250376.712 ops/s [Average] > ? (min, avg, max) = (18614233.510, 18764158.739, 19122478.453), stdev = > 165608.693 > ? CI (99.9%): [18513782.027, 19014535.452] (assumes normal distribution) > > Result "com.oracle.PutStringBench.putString": > ? 15920473.709 ?(99.9%) 1212446.652 ops/s [Average] > ? (min, avg, max) = (14842084.221, 15920473.709, 17371424.249), stdev = > 801958.390 > ? CI (99.9%): [14708027.056, 17132920.361] (assumes normal distribution) > > Benchmark? ? ? ? ? ? ? ? ? Mode? Cnt ? ? ? ? Score? ? ? ? Error? Units > PutStringBench.putString? thrpt? ? 5? 18571082.538 ? 693010.965? ops/s > > [b] after > > Result "com.oracle.PutStringBench.putString": > ? 108696688.710 ?(99.9%) 3774080.561 ops/s [Average] > ? (min, avg, max) = (101907400.750, 108696688.710, 110524934.117), > stdev = 2496320.615 > ? CI (99.9%): [104922608.149, 112470769.272] (assumes normal distribution) > > Result "com.oracle.PutStringBench.putString": > ? 103110531.621 ?(99.9%) 5281599.715 ops/s [Average] > ? (min, avg, max) = (96691960.810, 103110531.621, 106781180.294), stdev > = 3493451.195 > ? CI (99.9%): [97828931.906, 108392131.336] (assumes normal distribution) > > Benchmark? ? ? ? ? ? ? ? ? Mode? Cnt? ? ? ? ? Score ? ? ? ? Error? Units > PutStringBench.putString? thrpt? ? 5? 106026596.397 ? 1375553.439? ops/s > From Alan.Bateman at oracle.com Thu Feb 21 13:12:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 13:12:03 +0000 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> Message-ID: <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> On 21/02/2019 10:31, Claes Redestad wrote: > Hi Brian, > > patch looks good to me, but the new implementation will throw > BufferOverflowException before writing anything to the buffer, whereas > the old one would fill up the CharBuffer. Which case (CharBuffer sub-class) do you see this? The CharBuffer put(String, ...) methods are specified to throw BufferOverflowException and the implementation should be throwing this before copying any chars into the buffer. -Alan From claes.redestad at oracle.com Thu Feb 21 13:25:27 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 21 Feb 2019 14:25:27 +0100 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> Message-ID: On 2019-02-21 14:12, Alan Bateman wrote: > On 21/02/2019 10:31, Claes Redestad wrote: >> Hi Brian, >> >> patch looks good to me, but the new implementation will throw >> BufferOverflowException before writing anything to the buffer, whereas >> the old one would fill up the CharBuffer. > Which case (CharBuffer sub-class) do you see this? The CharBuffer > put(String, ...) methods are specified to throw BufferOverflowException > and the implementation should be throwing this before copying any chars > into the buffer. My bad, I based my faulty reasoning on the code in the bug rather than the existing template. Seems there's no observable difference in behavior here. /Claes From Alan.Bateman at oracle.com Thu Feb 21 14:43:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 14:43:49 +0000 Subject: NIO based SocketImpl to replace legacy PlainSocketImpl In-Reply-To: References: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com> Message-ID: <179696de-0340-8b1e-b802-2959ad59858b@oracle.com> Just another update on the effort to replace the legacy PlainSocketImpl. The changes in the sandbox are in good shape. I spent a bit of time comparing the behavior differences between the old and new implementations and I haven't found anything significant so far. Sergey Kuksenko has improved the micro benchmarks that exercise the socket APIs and we are about the same, or slightly better, which is good. I've drafted a JEP with all the details here: ?? http://openjdk.java.net/jeps/8218559 We will need help to test it. The Socket/ServerSocket APIs date from JDK 1.0 so it's likely there is a lot of dusty code using them. At the same time, newer libraries and servers have moved on to to the NIO APIs or something else. So if you have code using Socket/ServerSocket and have cycles to try it the changes in the sandbox then it would be very useful. -Alan From christoph.langer at sap.com Thu Feb 21 15:04:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 21 Feb 2019 15:04:40 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> Message-ID: <953449f0913340f6a94ae3d83611fd92@sap.com> Hi Alan, here is the next iteration: http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/ I focused on your comments regarding implementation details: > I'm not sure about using ${user.name} and "" as default. > Have you looked at using the zip file owner/group (or owner/owner on > Windows) as the default?? Also just wondering if 777 might be more > appropriate (maybe you have a reason for choosing 660?). It might be > useful to see what Linux, macOS and other operating systems do when > mounting a FAT file system. I'm using Files.getOwner() now as well as the default of 777 for permissions. > Did you consider using the string representation of the user, group and > permissions in the configuration properties? The zip file system > provider could support both of course. String might make it a bit easier > to create the map of configuration properties when creating the file > system e.g > Map.of("enablePosixPermissions", "true", "defaultOwner", "joe", > "defaultPermissions", "rw-rw---"); Implemented. I also added Lance's suggestions to the test. Are there other major implementation points left? If not I guess we should start refining the documentation... Thanks Christoph From brian.burkhalter at oracle.com Thu Feb 21 15:54:32 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 07:54:32 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> Message-ID: > On Feb 21, 2019, at 5:25 AM, Claes Redestad wrote: > > On 2019-02-21 14:12, Alan Bateman wrote: >> On 21/02/2019 10:31, Claes Redestad wrote: >>> Hi Brian, >>> >>> patch looks good to me, but the new implementation will throw >>> BufferOverflowException before writing anything to the buffer, whereas >>> the old one would fill up the CharBuffer. >> Which case (CharBuffer sub-class) do you see this? The CharBuffer put(String, ...) methods are specified to throw BufferOverflowException and the implementation should be throwing this before copying any chars into the buffer. > > My bad, I based my faulty reasoning on the code in the bug rather than > the existing template. Seems there's no observable difference in behavior here. Thanks for the comments. Should I consider this patch to have been reviewed? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Thu Feb 21 15:58:05 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 21 Feb 2019 16:58:05 +0100 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> Message-ID: On 2019-02-21 16:54, Brian Burkhalter wrote: > Thanks for the comments. Should I consider this patch to have been reviewed? Yes. Do as you may with the microbenchmark. :-) /Claes From brian.burkhalter at oracle.com Thu Feb 21 17:01:26 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 09:01:26 -0800 Subject: [ping] Re: 8048192: (bf) Out of direct buffer memory message should include the limits In-Reply-To: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> References: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> Message-ID: <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> Ping If we don?t want to improve the error message I suggest resolving this as ?Won?t Fix." > On Feb 14, 2019, at 8:25 AM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8048192 > > One possible solution is given below but I am not sure whether composing such an error string is desirable during bootstrap / startup. If this is undesirable then perhaps the issue should be resolved as WNF? > > Thanks, > > Brian > > --- a/src/java.base/share/classes/java/nio/Bits.java > +++ b/src/java.base/share/classes/java/nio/Bits.java > @@ -172,7 +172,11 @@ > } > > // no luck > - throw new OutOfMemoryError("Direct buffer memory"); > + throw new OutOfMemoryError > + ("Direct buffer memory: MAX_MEMORY = " + MAX_MEMORY > + + ", RESERVED_MEMORY = " + RESERVED_MEMORY.get() > + + ", TOTAL_CAPACITY = " + TOTAL_CAPACITY.get() > + + ", size = " + size + ", cap = " + cap); > > } finally { -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Thu Feb 21 17:05:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 21 Feb 2019 12:05:51 -0500 Subject: [ping] Re: 8048192: (bf) Out of direct buffer memory message should include the limits In-Reply-To: <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> References: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> Message-ID: <6d049f1e-e739-1577-3581-10a653c28b73@oracle.com> Hi Brian, That's fine, the string concat should be ok. its a bit wordy, but fine. +1, Roger On 02/21/2019 12:01 PM, Brian Burkhalter wrote: > Ping > > If we don?t want to improve the error message I suggest resolving this > as ?Won?t Fix." > >> On Feb 14, 2019, at 8:25 AM, Brian Burkhalter >> > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8048192 >> >> One possible solution is given below but I am not sure whether >> composing such an error string is desirable during bootstrap / >> startup. If this is undesirable then perhaps the issue should be >> resolved as WNF? >> >> Thanks, >> >> Brian >> >> --- a/src/java.base/share/classes/java/nio/Bits.java >> +++ b/src/java.base/share/classes/java/nio/Bits.java >> @@ -172,7 +172,11 @@ >> ?? ? ? ? ? ? } >> >> ?? ? ? ? ? ? // no luck >> -? ? ? ? ? ? throw new OutOfMemoryError("Direct buffer memory"); >> +? ? ? ? ? ? throw new OutOfMemoryError >> +? ? ? ? ? ? ? ? ("Direct buffer memory: MAX_MEMORY = " + MAX_MEMORY >> +? ? ? ? ? ? ? ? + ", RESERVED_MEMORY = " + RESERVED_MEMORY.get() >> +? ? ? ? ? ? ? ? + ", TOTAL_CAPACITY = " + TOTAL_CAPACITY.get() >> +? ? ? ? ? ? ? ? + ", size = " + size + ", cap = " + cap); >> >> ?? ? ? ? } finally { > From Alan.Bateman at oracle.com Thu Feb 21 17:29:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 17:29:36 +0000 Subject: [ping] Re: 8048192: (bf) Out of direct buffer memory message should include the limits In-Reply-To: <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> References: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> Message-ID: <66aa75e8-455f-9e89-1ade-7e6b2ec14abd@oracle.com> On 21/02/2019 17:01, Brian Burkhalter wrote: > Ping > > If we don?t want to improve the error message I suggest resolving this > as ?Won?t Fix." "MAX_MEMORY" or "TOTAL_CAPACITY" are the names of JDK internal fields so it might be better to leave those names out of the message. We ould be able to come up with shorter exception message to say that X bytes of direct memory cannot be allocated and have it include the current allocated and limit. -Alan From Alan.Bateman at oracle.com Thu Feb 21 17:40:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 17:40:18 +0000 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> Message-ID: On 21/02/2019 15:54, Brian Burkhalter wrote: > > Thanks for the comments. Should I consider this patch to have been > reviewed? > The implementation looks okay but I think we should harden it so that it reads the position once, not 3 times. If someone had a bug where they changed the position currently then it might lead to IOOBE or IAE. There are a few other places in the heap buffers that also need to be hardened a bit (direct buffers of course need to much more careful). -Alan From brian.burkhalter at oracle.com Thu Feb 21 17:41:45 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 09:41:45 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> Message-ID: > On Feb 21, 2019, at 9:40 AM, Alan Bateman wrote: > > On 21/02/2019 15:54, Brian Burkhalter wrote: >> >> Thanks for the comments. Should I consider this patch to have been reviewed? >> > The implementation looks okay but I think we should harden it so that it reads the position once, not 3 times. If someone had a bug where they changed the position currently then it might lead to IOOBE or IAE. Good point. I?ll fix it. > There are a few other places in the heap buffers that also need to be hardened a bit (direct buffers of course need to much more careful). Shall I try to include fixing those in this patch? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 21 17:45:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 17:45:23 +0000 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> Message-ID: <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> On 21/02/2019 17:41, Brian Burkhalter wrote: > >> There are a few other places in the heap buffers that also need to be >> hardened a bit (direct buffers of course need to much more careful). > > Shall I try to include fixing those in this patch? > Probably best to do it as a separate issue. I try to watch for these things with direct buffer classes as these could lead to any number of VM crashes or security issues. It's a less of concern with the heap buffers but would be good to fix if you have cycles. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 21 17:49:50 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 09:49:50 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> Message-ID: > On Feb 21, 2019, at 9:45 AM, Alan Bateman wrote: > > On 21/02/2019 17:41, Brian Burkhalter wrote: >> >>> There are a few other places in the heap buffers that also need to be hardened a bit (direct buffers of course need to much more careful). >> >> Shall I try to include fixing those in this patch? >> > Probably best to do it as a separate issue. I try to watch for these things with direct buffer classes as these could lead to any number of VM crashes or security issues. It's a less of concern with the heap buffers but would be good to fix if you have cycles. Updated patch below. It?s a little unclear where to put ?pos = position()?. I?ll file a separate issue for other hardening instances. Thanks, Brian +#if[char] + + public $Type$Buffer put(String src, int start, int end) { + int length = end - start; + checkBounds(start, length, src.length()); + if (isReadOnly()) + throw new ReadOnlyBufferException(); + if (length > remaining()) + throw new BufferOverflowException(); + int pos = position(); + src.getChars(start, end, hb, ix(pos)); + position(pos + length); + return this; + } + +#end[char] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 21 17:57:48 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 17:57:48 +0000 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> Message-ID: On 21/02/2019 17:49, Brian Burkhalter wrote: > >> On Feb 21, 2019, at 9:45 AM, Alan Bateman > > wrote: >> >> On 21/02/2019 17:41, Brian Burkhalter wrote: >>> >>>> There are a few other places in the heap buffers that also need to >>>> be hardened a bit (direct buffers of course need to much more careful). >>> >>> Shall I try to include fixing those in this patch? >>> >> Probably best to do it as a separate issue. I try to watch for these >> things with direct buffer classes as these could lead to any number >> of VM crashes or security issues. It's a less of concern with the >> heap buffers but would be good to fix if you have cycles. > > Updated patch below. It?s a little unclear where to put ?pos = > position()?. remaining() also reads the position? so I think you want: int pos = src.position(); int lim = src.limit(); int rem = (pos <= lim) ? lim - pos : 0; -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 21 18:07:23 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 10:07:23 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> Message-ID: <8938D67E-9012-436E-8958-C90B556F6781@oracle.com> > On Feb 21, 2019, at 9:57 AM, Alan Bateman wrote: > >> Updated patch below. It?s a little unclear where to put ?pos = position()?. > remaining() also reads the position so I think you want: > > int pos = src.position(); > int lim = src.limit(); > int rem = (pos <= lim) ? lim - pos : 0; Oh, your are correct but I don?t think we want ?src.?. Thanks, Brian +#if[char] + + public $Type$Buffer put(String src, int start, int end) { + int length = end - start; + checkBounds(start, length, src.length()); + if (isReadOnly()) + throw new ReadOnlyBufferException(); + int pos = position(); + int lim = limit(); + int rem = (pos <= lim) ? lim - pos : 0; + if (length > rem) + throw new BufferOverflowException(); + src.getChars(start, end, hb, ix(pos)); + position(pos + length); + return this; + } + +#end[char] -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 21 20:30:29 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 12:30:29 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <8938D67E-9012-436E-8958-C90B556F6781@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> <8938D67E-9012-436E-8958-C90B556F6781@oracle.com> Message-ID: <12EDE4D8-868A-4E67-8FC4-819D092D9045@oracle.com> > On Feb 21, 2019, at 10:07 AM, Brian Burkhalter wrote: > > >> On Feb 21, 2019, at 9:57 AM, Alan Bateman > wrote: >> >>> Updated patch below. It?s a little unclear where to put ?pos = position()?. >> remaining() also reads the position so I think you want: >> >> int pos = src.position(); >> int lim = src.limit(); >> int rem = (pos <= lim) ? lim - pos : 0; > > Oh, your are correct but I don?t think we want ?src.? I created a webrev including an updated benchmark: http://cr.openjdk.java.net/~bpb/8011135/webrev/ Before and after results are: ? Before ? Benchmark (numChars) Mode Cnt Score Error Units CharBuffers.putString 2 avgt 5 11.546 ? 1.070 ns/op CharBuffers.putString 256 avgt 5 287.714 ? 11.479 ns/op CharBuffers.putString 16384 avgt 5 16768.276 ? 110.839 ns/op ? After ? Benchmark (numChars) Mode Cnt Score Error Units CharBuffers.putString 2 avgt 5 10.790 ? 0.394 ns/op CharBuffers.putString 256 avgt 5 18.867 ? 0.402 ns/op CharBuffers.putString 16384 avgt 5 1218.156 ? 25.454 ns/op Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 21 21:09:11 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 13:09:11 -0800 Subject: [ping] Re: 8048192: (bf) Out of direct buffer memory message should include the limits In-Reply-To: <66aa75e8-455f-9e89-1ade-7e6b2ec14abd@oracle.com> References: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> <66aa75e8-455f-9e89-1ade-7e6b2ec14abd@oracle.com> Message-ID: <1ABDA6F3-FA4C-499D-836B-C8DBE14C9EA9@oracle.com> > On Feb 21, 2019, at 9:29 AM, Alan Bateman wrote: > > On 21/02/2019 17:01, Brian Burkhalter wrote: >> Ping >> >> If we don?t want to improve the error message I suggest resolving this as ?Won?t Fix." > "MAX_MEMORY" or "TOTAL_CAPACITY" are the names of JDK internal fields so it might be better to leave those names out of the message. We ould be able to come up with shorter exception message to say that X bytes of direct memory cannot be allocated and have it include the current allocated and limit. Here is an updated version: @@ -172,8 +172,11 @@ } // no luck - throw new OutOfMemoryError("Direct buffer memory"); - + throw new OutOfMemoryError + ("Cannot reserve " + + size + " bytes of direct buffer memory (allocated: " + + RESERVED_MEMORY.get() + ", limit: " + MAX_MEMORY +")"); + } finally { Example error: bpb:CharBufferPutString{6}$ java -XX:MaxDirectMemorySize=42 -jar target/benchmarks.jar -f 1 -wi 5 -w 5 -i 5 -r 5 Error occurred during initialization of boot layer java.lang.OutOfMemoryError: Cannot reserve 8192 bytes of direct buffer memory (allocated: 0, limit: 42) Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Thu Feb 21 21:37:58 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 21 Feb 2019 16:37:58 -0500 Subject: [ping] Re: 8048192: (bf) Out of direct buffer memory message should include the limits In-Reply-To: <1ABDA6F3-FA4C-499D-836B-C8DBE14C9EA9@oracle.com> References: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> <66aa75e8-455f-9e89-1ade-7e6b2ec14abd@oracle.com> <1ABDA6F3-FA4C-499D-836B-C8DBE14C9EA9@oracle.com> Message-ID: <36625497-7e78-ba02-1411-4461f8deb028@oracle.com> Hi Brian, Nicely reworded,? Looks good. Do any of the existing direct buffer tests exercise that exception? If not, can one be improved to do so. Check the copyright date too. Thanks, Roger On 2/21/19 4:09 PM, Brian Burkhalter wrote: > >> On Feb 21, 2019, at 9:29 AM, Alan Bateman > > wrote: >> >> On 21/02/2019 17:01, Brian Burkhalter wrote: >>> Ping >>> >>> If we don?t want to improve the error message I suggest resolving >>> this as ?Won?t Fix." >> "MAX_MEMORY" or "TOTAL_CAPACITY" are the names of JDK internal fields >> so it might be better to leave those names out of the message. We >> ould be able to come up with shorter exception message to say that X >> bytes of direct memory cannot be allocated and have it include the >> current allocated and limit. > > Here is an updated version: > > @@ -172,8 +172,11 @@ > ? ? ? ? ? } > > > ? ? ? ? ? // no luck > - ? ? ? ? ? throw new OutOfMemoryError("Direct buffer memory"); > - > + ? ? ? ? ? throw new OutOfMemoryError > + ? ? ? ? ? ? ? ("Cannot reserve " > + ? ? ? ? ? ? ? ? + size + " bytes of direct buffer memory (allocated: " > + ? ? ? ? ? ? ? ? + RESERVED_MEMORY.get() + ", limit: " + MAX_MEMORY > +")"); > + > ? ? ? } finally { > > Example error: > > bpb:CharBufferPutString{6}$ java -XX:MaxDirectMemorySize=42 -jar > target/benchmarks.jar -f 1 -wi 5 -w 5 -i 5 -r 5 > Error occurred during initialization of boot layer > java.lang.OutOfMemoryError: Cannot reserve 8192 bytes of direct buffer > memory (allocated: 0, limit: 42) > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 21 22:00:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Feb 2019 14:00:30 -0800 Subject: [ping] Re: 8048192: (bf) Out of direct buffer memory message should include the limits In-Reply-To: <36625497-7e78-ba02-1411-4461f8deb028@oracle.com> References: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> <66aa75e8-455f-9e89-1ade-7e6b2ec14abd@oracle.com> <1ABDA6F3-FA4C-499D-836B-C8DBE14C9EA9@oracle.com> <36625497-7e78-ba02-1411-4461f8deb028@oracle.com> Message-ID: <2F765332-51EE-4A9E-9648-8A35ED220F1E@oracle.com> HI Roger, > On Feb 21, 2019, at 1:37 PM, Roger Riggs wrote: > > Nicely reworded, Looks good. Cool. > Do any of the existing direct buffer tests exercise that exception? > If not, can one be improved to do so. Yes: java/nio/Buffer/LimitDirectMemory.java > Check the copyright date too. Done: it?s OK. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 22 11:04:01 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2019 11:04:01 +0000 Subject: [ping] Re: 8048192: (bf) Out of direct buffer memory message should include the limits In-Reply-To: <1ABDA6F3-FA4C-499D-836B-C8DBE14C9EA9@oracle.com> References: <4E33A50E-EA32-4D13-AC24-A4C7D9172A4F@oracle.com> <4D8B4095-049F-44A5-B9C3-7ADE7AA04A68@oracle.com> <66aa75e8-455f-9e89-1ade-7e6b2ec14abd@oracle.com> <1ABDA6F3-FA4C-499D-836B-C8DBE14C9EA9@oracle.com> Message-ID: On 21/02/2019 21:09, Brian Burkhalter wrote: > >> On Feb 21, 2019, at 9:29 AM, Alan Bateman > > wrote: >> >> On 21/02/2019 17:01, Brian Burkhalter wrote: >>> Ping >>> >>> If we don?t want to improve the error message I suggest resolving >>> this as ?Won?t Fix." >> "MAX_MEMORY" or "TOTAL_CAPACITY" are the names of JDK internal fields >> so it might be better to leave those names out of the message. We >> ould be able to come up with shorter exception message to say that X >> bytes of direct memory cannot be allocated and have it include the >> current allocated and limit. > > Here is an updated version: This version looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 22 11:16:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Feb 2019 11:16:26 +0000 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <12EDE4D8-868A-4E67-8FC4-819D092D9045@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> <8938D67E-9012-436E-8958-C90B556F6781@oracle.com> <12EDE4D8-868A-4E67-8FC4-819D092D9045@oracle.com> Message-ID: <3dc39c8d-758d-6d94-dea9-000acfb3e333@oracle.com> On 21/02/2019 20:30, Brian Burkhalter wrote: > > I created a webrev including an updated benchmark: > > http://cr.openjdk.java.net/~bpb/8011135/webrev/ This version looks good. Claes might have some comments on the microbenchmark, my only comment that future maintainers might wonder about the +42 and also why the position is reset to 21 (I assume it would be buf.clear(); buf.put(str); -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 22 15:18:44 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2019 07:18:44 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <3dc39c8d-758d-6d94-dea9-000acfb3e333@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> <8938D67E-9012-436E-8958-C90B556F6781@oracle.com> <12EDE4D8-868A-4E67-8FC4-819D092D9045@oracle.com> <3dc39c8d-758d-6d94-dea9-000acfb3e333@oracle.com> Message-ID: <4E09EEED-DEAC-4705-B1D6-7E794B4CFF3E@oracle.com> > On Feb 22, 2019, at 3:16 AM, Alan Bateman wrote: > > On 21/02/2019 20:30, Brian Burkhalter wrote: >> >> I created a webrev including an updated benchmark: >> >> http://cr.openjdk.java.net/~bpb/8011135/webrev/ This version looks good. > > Claes might have some comments on the microbenchmark, my only comment that future maintainers might wonder about the +42 and also why the position is reset to 21 (I assume it would be buf.clear(); buf.put(str); No good reason really. The 21 and 42 can be removed if we like. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 22 15:34:53 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2019 07:34:53 -0800 Subject: 8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char In-Reply-To: <4E09EEED-DEAC-4705-B1D6-7E794B4CFF3E@oracle.com> References: <77D486E4-CE5C-4620-8CFB-FEF1F9F125DB@oracle.com> <2648347d-012f-b886-e3c1-5b39479136d9@oracle.com> <6d1362c2-9b0b-d712-25b5-2a0853f94bb8@oracle.com> <7b5f9678-baef-6f25-6f76-46c3c355b625@oracle.com> <8938D67E-9012-436E-8958-C90B556F6781@oracle.com> <12EDE4D8-868A-4E67-8FC4-819D092D9045@oracle.com> <3dc39c8d-758d-6d94-dea9-000acfb3e333@oracle.com> <4E09EEED-DEAC-4705-B1D6-7E794B4CFF3E@oracle.com> Message-ID: > On Feb 22, 2019, at 7:18 AM, Brian Burkhalter wrote: > >>> http://cr.openjdk.java.net/~bpb/8011135/webrev/ This version looks good. >> >> Claes might have some comments on the microbenchmark, my only comment that future maintainers might wonder about the +42 and also why the position is reset to 21 (I assume it would be buf.clear(); buf.put(str); > > No good reason really. The 21 and 42 can be removed if we like. I updated the benchmark as below and re-ran it to verify. I?ll push this version unless I see an objection. Thanks, Brian --- a/test/micro/org/openjdk/bench/java/nio/CharBuffers.java +++ b/test/micro/org/openjdk/bench/java/nio/CharBuffers.java @@ -54,13 +54,12 @@ char[] c = new char[numChars]; Arrays.fill(c, 'X'); str = String.valueOf(c); - buf = CharBuffer.allocate(numChars + 42); + buf = CharBuffer.allocate(numChars); } @Benchmark public CharBuffer putString() { - buf.rewind(); - buf.position(21); + buf.clear(); return buf.put(str); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 22 23:34:23 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Feb 2019 15:34:23 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) Message-ID: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> Please review the proposed fix [1] for issue [2] the CSR of which is [3]. The fix changes the existing package scope slice(int,int) method to be slice(index,length) instead of slice(position,limit) and modifies alignedSlice() accordingly. Overrides are added as needed for heap, direct, view, and StringChar buffers. I suggest perhaps addressing the specification content first so that the CSR can move forward. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/5071718/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-5071718 [3] https://bugs.openjdk.java.net/browse/JDK-8219608 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Feb 23 18:15:24 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Feb 2019 18:15:24 +0000 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> Message-ID: <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> On 22/02/2019 23:34, Brian Burkhalter wrote: > Please review the proposed fix [1] for issue [2] the CSR of which is > [3]. The fix changes the existing package scope slice(int,int) method > to be slice(index,length) instead of slice(position,limit) and > modifies alignedSlice() accordingly. Overrides are added as needed for > heap, direct, view, and StringChar buffers. > > I suggest perhaps addressing the specification content first so that > the CSR can move forward. > I think this looks okay. The usefulness will be mostly ByteBuffer but I think okay to have it defined by each of the buffer classes. The "Additional operations" section in Buffer's javadoc will need a small update to mention the 2-arg slice. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Feb 25 08:31:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2019 08:31:03 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <953449f0913340f6a94ae3d83611fd92@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> Message-ID: <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> On 21/02/2019 15:04, Langer, Christoph wrote: > Hi Alan, > > here is the next iteration:http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/ > > I focused on your comments regarding implementation details: > > : > Are there other major implementation points left? If not I guess we should start refining the documentation... I think it would be useful to write down a summary of the proposal as there are several detailed points that we've been discussing in this thread that reviewers will need to understand the proposal before diving into the implementation/patch.? This might also help getting the javadoc aligned, and eventually the CSR. Here's where I think we are: 1. By default, a zip file system will have no support for the "posix" and "owner" views of file attributes, this means the following will fail with UOE: ? PosixFileAttributes attrs = Files.readAttributes(file, PosixFileAttributes.class); and the zip file system's supportedFileAttributView method will not include "posix". 2. Creating a zip file system with configuration parameter XXX set to "true" will create the zip file system that supports PosixFileAttributeView (and FileOwnerAttributeView). The current patch names the configuration parameter "posix". That name might be misleading as a configuration parameter as it conveys more than it actually does. Something like "enablePosixFileAttributes" clear conveys that it enables support for POSIX file attribute but might be a better wordy. The value in the configuration map is documented as Boolean but I think we are allowing it to be the string representation of a Boolean, meaning it can be "true" or "false" like we have with the "create" parameter. 3. The map of configurations parameters can optionally include the parameters "defaultOwner", "defaultGroup", and "defaultPermissions" with the default owner/group/permissions to return. These names seem okay to me. For the owner/group, the parameter type can be UserPrincipal/GroupPrincipal or strings. If the value is a String then we need to decide if there is any validation. If I read the current patch correctly then it doesn't do any validation - that might be okay but minimally maybe we should disallow the empty string. If the defaultXXX parameters aren't present then the zip file owner/group would be a sensible default. If the zip file is on a file store that supports FileOwnerAttributeView then we've got the owner. If the file store supports PosixFileAttributeView then we have a group owner. If PosixFileAttributeView is not supported then using the owner as the group is okay. I see the current patch as a fallback to fallback to "" but I'd prefer not have that because it will be very confusing to diagnose if there are issues. For defaultPermissions, the value is a Set or the string representation. In the implementation, initPermissions can be changed to use PosixFilePermissions.fromString as it does the translation that we need. 4. As an alternative to the type safe access that PosixFileAttributeView provides, the proposal is to document the "zip" view of file attributes. Initially, it will admit to one file attribute for the permissions. The current patch uses the name "storedPermissions" but it might be simpler to use "permissions" so that "zip:permissions" and "posix:permissions" are the same when the zip entry has permissions. With this support you can write code like this: ??? Set perms = (Set) Files.getAttribute(file, "zip:permissions"); The cast is ugly of course but that's the consequence of not exposing ZipFileAttributes in the API so there is no type token to specify on the RHS. Documenting the "zip" view brings up a few issues, e.g. will Files.readAttributes(file, "zip:*") reveal more than "permissions". For this API it is okay for the map to attributes beyond the specified list. 5. There will be no support for specifying as POSIX FileAttribute to createFile or createDirectory to atomically set the permissions when creating a new file/directory, UOE will thrown as is is now. Is this a reasonable summary? -Alan From Roger.Riggs at oracle.com Mon Feb 25 14:48:11 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 25 Feb 2019 09:48:11 -0500 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> Message-ID: Hi Brian, Is it intentional to prevent being able to create a zero length slice at index == limit? Buffer: 618: and 628 with regards to the IOOBE index must be non-negative and less than limit() I think that forces application code to do some unnecessary workarounds at a boundary condition. The relative slice() method does not restrict the case where position() == limit(). Thanks, Roger On 02/23/2019 01:15 PM, Alan Bateman wrote: > On 22/02/2019 23:34, Brian Burkhalter wrote: >> Please review the proposed fix [1] for issue [2] the CSR of which is >> [3]. The fix changes the existing package scope slice(int,int) method >> to be slice(index,length) instead of slice(position,limit) and >> modifies alignedSlice() accordingly. Overrides are added as needed >> for heap, direct, view, and StringChar buffers. >> >> I suggest perhaps addressing the specification content first so that >> the CSR can move forward. >> > I think this looks okay. The usefulness will be mostly ByteBuffer but > I think okay to have it defined by each of the buffer classes. The > "Additional operations" section in Buffer's javadoc will need a small > update to mention the 2-arg slice. > > -Alan. From brian.burkhalter at oracle.com Mon Feb 25 15:32:55 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Feb 2019 07:32:55 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> Message-ID: <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> Hi Alan, Roger, > On Feb 25, 2019, at 6:48 AM, Roger Riggs wrote: > > Is it intentional to prevent being able to create a zero length slice > at index == limit? > > Buffer: 618: and 628 with regards to the IOOBE > > index must be non-negative and less than limit() > > I think that forces application code to do some unnecessary workarounds > at a boundary condition. > > The relative slice() method does not restrict the case where position() == limit(). Good point. I will change it accordingly. > On 02/23/2019 01:15 PM, Alan Bateman wrote: >> On 22/02/2019 23:34, Brian Burkhalter wrote: >>> Please review the proposed fix [1] for issue [2] the CSR of which is [3]. The fix changes the existing package scope slice(int,int) method to be slice(index,length) instead of slice(position,limit) and modifies alignedSlice() accordingly. Overrides are added as needed for heap, direct, view, and StringChar buffers. >>> >>> I suggest perhaps addressing the specification content first so that the CSR can move forward. >>> >> I think this looks okay. The usefulness will be mostly ByteBuffer but I think okay to have it defined by each of the buffer classes. The "Additional operations" section in Buffer's javadoc will need a small update to mention the 2-arg slice. I was wondering about adding some doc there. Will update. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Feb 25 18:07:29 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Feb 2019 18:07:29 +0000 Subject: rsocket Issue #2 In-Reply-To: <30221E7B-916A-45C9-8B74-E3DB9CA682AA@oracle.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> <1828884A29C6694DAF28B7E6B8A82373B3DEA4C1@ORSMSX109.amr.corp.intel.com> <30221E7B-916A-45C9-8B74-E3DB9CA682AA@oracle.com> Message-ID: <170ce74e-6b3d-c82f-7199-f1ec6fbc0495@oracle.com> Sean, On 13/02/2019 22:00, Chris Hegarty wrote: > > On 13 Feb 2019, at 19:06, Hefty, Sean wrote: > >>> The `rpoll` behaviour I observe is clearly different than regular >>> `poll` ( which will wake up all waiters ). Is this a bug, or expected >>> behaviour of the thread-less rsocket implementation? >> >> This is likely an implementation issue, but the intent should be to mimic poll behavior here. So I would consider this a bug, and it would take some work to figure out how to handle this in a way that doesn't result in races. > > Sure. Is it possible to get this issue into the librdma bug tracking system, and have it evaluated. Has this issue been filed in the librdma bug tracking system? I see this issue, along with the previous issue I reported [1], as potential blockers for the integration of the RDMA support in the JDK. -Chris. [1] https://mail.openjdk.java.net/pipermail/nio-dev/2018-December/005651.html From brian.burkhalter at oracle.com Mon Feb 25 21:41:25 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Feb 2019 13:41:25 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> Message-ID: Updated [1] to allow for the case ?slice(limit(),0)' with no IOOBE and to add ?slice(int,int)? to the ?additional operations? section of the Buffer class-level specification. The CSR [2] description has also been updated but not the specdiff attachment: will hold off on that until the verbiage is agreed upon. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/5071718/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8219608 From chris.hegarty at oracle.com Mon Feb 25 22:19:57 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Feb 2019 22:19:57 +0000 Subject: rsocket Issue #2 In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373B3DEF259@ORSMSX109.amr.corp.intel.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> <1828884A29C6694DAF28B7E6B8A82373B3DEA4C1@ORSMSX109.amr.corp.intel.com> <30221E7B-916A-45C9-8B74-E3DB9CA682AA@oracle.com> <170ce74e-6b3d-c82f-7199-f1ec6fbc0495@oracle.com> <1828884A29C6694DAF28B7E6B8A82373B3DEF259@ORSMSX109.amr.corp.intel.com> Message-ID: <4278FCF3-ACA3-4C15-9EAE-6E95EED26CFD@oracle.com> Forgive me, but how do issues like the ones that we?ve encountered get fixed? Intel have contributors in this area, right? -Chris On 25 Feb 2019, at 19:51, Hefty, Sean wrote: >>>>> The `rpoll` behaviour I observe is clearly different than regular >>>>> `poll` ( which will wake up all waiters ). Is this a bug, or expected >>>>> behaviour of the thread-less rsocket implementation? >>>> >>>> This is likely an implementation issue, but the intent should be to mimic >> poll behavior here. So I would consider this a bug, and it would take some >> work to figure out how to handle this in a way that doesn't result in races. >>> >>> Sure. Is it possible to get this issue into the librdma bug tracking system, >> and have it evaluated. >> >> Has this issue been filed in the librdma bug tracking system? > > There isn't a bug tracking system for any rdma-core components, which librdmacm is one of. All bugs are just to be reported via an email to the linux-rdma kernel mailing list. > > I know Lucy submitted 1 or 2 issues to that mailing list, but I don't believe she ever received a response to any of them. I can submit an email to that mailing list, but I would not anticipate any response to it. > > - Sean From brent.christian at oracle.com Tue Feb 26 00:30:18 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 25 Feb 2019 16:30:18 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> Message-ID: <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> A nit for the new javadoc: I find it a little weird for one paragraph to start, "The new buffer will start at position {@code index}...", and the next paragraph to start, "The new buffer's position will be zero." I find the no-arg slice()'s reference to "the content of the new buffer" to be a bit clearer. So my suggestion would be, e.g.: "The content of the new buffer will start at position {@code index} in this buffer, and will contain {@code length} elements." Thanks, -Brent On 2/25/19 1:41 PM, Brian Burkhalter wrote: > Updated [1] to allow for the case ?slice(limit(),0)' with no IOOBE and to add ?slice(int,int)? to the ?additional operations? section of the Buffer class-level specification. > > The CSR [2] description has also been updated but not the specdiff attachment: will hold off on that until the verbiage is agreed upon. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/5071718/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8219608 > From brian.burkhalter at oracle.com Tue Feb 26 01:48:25 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Feb 2019 17:48:25 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> Message-ID: <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> Hi Brent, That does read better. I?ll hold off on updating the webrev however until more comments come in. Thanks, Brian > On Feb 25, 2019, at 4:30 PM, Brent Christian wrote: > > A nit for the new javadoc: > > I find it a little weird for one paragraph to start, "The new buffer will start at position {@code index}...", and the next paragraph to start, "The new buffer's position will be zero." > > I find the no-arg slice()'s reference to "the content of the new buffer" to be a bit clearer. So my suggestion would be, e.g.: > > "The content of the new buffer will start at position {@code index} in this buffer, and will contain {@code length} elements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.hefty at intel.com Wed Feb 13 19:06:15 2019 From: sean.hefty at intel.com (Hefty, Sean) Date: Wed, 13 Feb 2019 19:06:15 +0000 Subject: rsocket Issue #2 In-Reply-To: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> Message-ID: <1828884A29C6694DAF28B7E6B8A82373B3DEA4C1@ORSMSX109.amr.corp.intel.com> > The `rpoll` behaviour I observe is clearly different than regular > `poll` ( which will wake up all waiters ). Is this a bug, or expected > behaviour of the thread-less rsocket implementation? This is likely an implementation issue, but the intent should be to mimic poll behavior here. So I would consider this a bug, and it would take some work to figure out how to handle this in a way that doesn't result in races. - Sean From sean.hefty at intel.com Mon Feb 25 19:51:14 2019 From: sean.hefty at intel.com (Hefty, Sean) Date: Mon, 25 Feb 2019 19:51:14 +0000 Subject: rsocket Issue #2 In-Reply-To: <170ce74e-6b3d-c82f-7199-f1ec6fbc0495@oracle.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> <1828884A29C6694DAF28B7E6B8A82373B3DEA4C1@ORSMSX109.amr.corp.intel.com> <30221E7B-916A-45C9-8B74-E3DB9CA682AA@oracle.com> <170ce74e-6b3d-c82f-7199-f1ec6fbc0495@oracle.com> Message-ID: <1828884A29C6694DAF28B7E6B8A82373B3DEF259@ORSMSX109.amr.corp.intel.com> > >>> The `rpoll` behaviour I observe is clearly different than regular > >>> `poll` ( which will wake up all waiters ). Is this a bug, or expected > >>> behaviour of the thread-less rsocket implementation? > >> > >> This is likely an implementation issue, but the intent should be to mimic > poll behavior here. So I would consider this a bug, and it would take some > work to figure out how to handle this in a way that doesn't result in races. > > > > Sure. Is it possible to get this issue into the librdma bug tracking system, > and have it evaluated. > > Has this issue been filed in the librdma bug tracking system? There isn't a bug tracking system for any rdma-core components, which librdmacm is one of. All bugs are just to be reported via an email to the linux-rdma kernel mailing list. I know Lucy submitted 1 or 2 issues to that mailing list, but I don't believe she ever received a response to any of them. I can submit an email to that mailing list, but I would not anticipate any response to it. - Sean From sean.hefty at intel.com Mon Feb 25 22:25:19 2019 From: sean.hefty at intel.com (Hefty, Sean) Date: Mon, 25 Feb 2019 22:25:19 +0000 Subject: rsocket Issue #2 In-Reply-To: <4278FCF3-ACA3-4C15-9EAE-6E95EED26CFD@oracle.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> <1828884A29C6694DAF28B7E6B8A82373B3DEA4C1@ORSMSX109.amr.corp.intel.com> <30221E7B-916A-45C9-8B74-E3DB9CA682AA@oracle.com> <170ce74e-6b3d-c82f-7199-f1ec6fbc0495@oracle.com> <1828884A29C6694DAF28B7E6B8A82373B3DEF259@ORSMSX109.amr.corp.intel.com> <4278FCF3-ACA3-4C15-9EAE-6E95EED26CFD@oracle.com> Message-ID: <1828884A29C6694DAF28B7E6B8A82373B3DEF3F6@ORSMSX109.amr.corp.intel.com> Intel has contributors to the RDMA subsystem. Lucy is the only person I know currently working on rsockets code specifically. I will check her group and our Ethernet group to see if I can locate someone to assist her since she's out. - Sean > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Monday, February 25, 2019 2:20 PM > To: Hefty, Sean > Cc: Lu, Yingqi ; nio-dev at openjdk.java.net; Viswanathan, > Sandhya ; Kaczmarek, Eric > ; Aundhe, Shirish > Subject: Re: rsocket Issue #2 > > Forgive me, but how do issues like the ones that we?ve encountered get fixed? > Intel have contributors in this area, right? > > -Chris > > On 25 Feb 2019, at 19:51, Hefty, Sean wrote: > > >>>>> The `rpoll` behaviour I observe is clearly different than regular > >>>>> `poll` ( which will wake up all waiters ). Is this a bug, or expected > >>>>> behaviour of the thread-less rsocket implementation? > >>>> > >>>> This is likely an implementation issue, but the intent should be to mimic > >> poll behavior here. So I would consider this a bug, and it would take some > >> work to figure out how to handle this in a way that doesn't result in > races. > >>> > >>> Sure. Is it possible to get this issue into the librdma bug tracking > system, > >> and have it evaluated. > >> > >> Has this issue been filed in the librdma bug tracking system? > > > > There isn't a bug tracking system for any rdma-core components, which > librdmacm is one of. All bugs are just to be reported via an email to the > linux-rdma kernel mailing list. > > > > I know Lucy submitted 1 or 2 issues to that mailing list, but I don't > believe she ever received a response to any of them. I can submit an email to > that mailing list, but I would not anticipate any response to it. > > > > - Sean From Alan.Bateman at oracle.com Tue Feb 26 08:43:52 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2019 08:43:52 +0000 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> Message-ID: On 26/02/2019 01:48, Brian Burkhalter wrote: > Hi Brent, > > That does read better. It's consistent with the existing slice method so I think it's good too. Otherwise looks good to me, kudos to Roger for spotting the error with the 0 length case, that would have been embarrassing to get wrong. -Alan From brian.burkhalter at oracle.com Tue Feb 26 15:55:32 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Feb 2019 07:55:32 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> Message-ID: > On Feb 26, 2019, at 12:43 AM, Alan Bateman wrote: > > On 26/02/2019 01:48, Brian Burkhalter wrote: >> Hi Brent, >> >> That does read better. > It's consistent with the existing slice method so I think it's good too. Webrev [1] and CSR [2] updated accordingly. > Otherwise looks good to me, kudos to Roger for spotting the error with the 0 length case, that would have been embarrassing to get wrong. Indeed: good catch, Roger! Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/5071718/webrev.02/ [2] https://bugs.openjdk.java.net/browse/JDK-8219608 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Tue Feb 26 16:46:46 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Feb 2019 11:46:46 -0500 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> Message-ID: <59936a24-48cf-a7a6-610e-9a1c9f6716c7@oracle.com> Hi Brian, Nice updates. CSR: The summary line should stand on it own. It should explicitly mention ByteBuffer or XXXBuffer by name and name the new method. For example. "Add a slice method to ByteBuffer and Buffer to create a subsequence given an absolute position and size." I would use present tense instead of future tense. The future tense could be read as being indefinite about when that is true. "will be" -> "are" But it is consistent with existing methods. Buffer.java: 141: it looks odd to have capital "It" after ":" Thanks, Roger On 02/26/2019 10:55 AM, Brian Burkhalter wrote: > >> On Feb 26, 2019, at 12:43 AM, Alan Bateman > > wrote: >> >> On 26/02/2019 01:48, Brian Burkhalter wrote: >>> Hi Brent, >>> >>> That does read better. >> It's consistent with the existing slice method so I think it's good too. > > Webrev [1] and CSR [2] updated accordingly. > >> Otherwise looks good to me, kudos to Roger for spotting the error >> with the 0 length case, that would have been embarrassing to get wrong. > > Indeed: good catch, Roger! > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/5071718/webrev.02/ > > [2] https://bugs.openjdk.java.net/browse/JDK-8219608 From brian.burkhalter at oracle.com Tue Feb 26 17:30:46 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Feb 2019 09:30:46 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: <59936a24-48cf-a7a6-610e-9a1c9f6716c7@oracle.com> References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> <59936a24-48cf-a7a6-610e-9a1c9f6716c7@oracle.com> Message-ID: <6BB3F539-B104-4A67-991E-E0CFBB595C6F@oracle.com> Hi Roger, > On Feb 26, 2019, at 8:46 AM, Roger Riggs wrote: > > Nice updates. Thanks. > CSR: > > The summary line should stand on it own. > It should explicitly mention ByteBuffer or XXXBuffer by name and name the new method. For example. > > "Add a slice method to ByteBuffer and Buffer to create a subsequence given an absolute position and size.? Changed to "Add a slice method to Buffer and its type specific subclasses to create a subsequence given an absolute position and size.? > I would use present tense instead of future tense. > The future tense could be read as being indefinite about when that is true. > "will be" -> "are" > But it is consistent with existing methods. > > Buffer.java: 141: it looks odd to have capital "It" after ":" Both of the above are consistent with existing javadoc so I don?t know that the new text should differ. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 26 17:32:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2019 17:32:15 +0000 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> Message-ID: On 26/02/2019 15:55, Brian Burkhalter wrote: > >> On Feb 26, 2019, at 12:43 AM, Alan Bateman > > wrote: >> >> On 26/02/2019 01:48, Brian Burkhalter wrote: >>> Hi Brent, >>> >>> That does read better. >> It's consistent with the existing slice method so I think it's good too. > > Webrev [1] and CSR [2] updated accordingly. > One small suggestion for the class description is to merge the two paragraphs on the slice methods into one to avoid the duplicate wording, it might be as simpler as "The slice() and slice(int,int) methods create a subsequence of a buffer; They leave the limit and position unchanged". -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 26 17:41:05 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Feb 2019 09:41:05 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> Message-ID: > On Feb 26, 2019, at 9:32 AM, Alan Bateman wrote: > > One small suggestion for the class description is to merge the two paragraphs on the slice methods into one to avoid the duplicate wording, it might be as simpler as "The slice() and slice(int,int) methods create a subsequence of a buffer; They leave the limit and position unchanged". Voila: *
  • The {@link #slice} and {@link #slice(int,int) slice(index,length)} * methods create a subsequence of a buffer: They leave the limit and the * position unchanged.

  • Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 27 01:06:52 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Feb 2019 17:06:52 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> Message-ID: <5A30B625-7CDC-436E-A903-7FCA2B701597@oracle.com> > On Feb 26, 2019, at 9:41 AM, Brian Burkhalter wrote: > >> On Feb 26, 2019, at 9:32 AM, Alan Bateman > wrote: >> >> One small suggestion for the class description is to merge the two paragraphs on the slice methods into one to avoid the duplicate wording, it might be as simpler as "The slice() and slice(int,int) methods create a subsequence of a buffer; They leave the limit and position unchanged". > > Voila: > > *
  • The {@link #slice} and {@link #slice(int,int) slice(index,length)} > * methods create a subsequence of a buffer: They leave the limit and the > * position unchanged.

  • I created one more webrev [1] which includes the above change and adds some test coverage in java/nio/Buffer/StringCharBufferSliceTest.java which had been lacking. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/5071718/webrev.03/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 27 19:36:16 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Feb 2019 11:36:16 -0800 Subject: 8219597: (bf) Heap buffer state changes could provoke unexpected exceptions Message-ID: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> This issue [1] was instigated by this comment [2]. The change [3] hopefully reduces the exposure of heap buffers to changes in the buffer state, notably the position (cursor). Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8219597 [2] http://mail.openjdk.java.net/pipermail/nio-dev/2019-February/005900.html [3] http://cr.openjdk.java.net/~bpb/8219597/webrev.00/ From roger.riggs at oracle.com Wed Feb 27 20:10:03 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 27 Feb 2019 15:10:03 -0500 Subject: 8219597: (bf) Heap buffer state changes could provoke unexpected exceptions In-Reply-To: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> References: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> Message-ID: <9e400b53-23e1-0c3c-edec-e38018d3035a@oracle.com> Hi Brian, The changes look fine. Alan's comments not withstanding, I'd be inclined to close it as WNF because it does not improve the concurrency situation and may further hide cases where the caller should be doing synchronization. With this change will be harder to observe that something is going wrong. Roger On 2/27/19 2:36 PM, Brian Burkhalter wrote: > This issue [1] was instigated by this comment [2]. The change [3] hopefully reduces the exposure of heap buffers to changes in the buffer state, notably the position (cursor). > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8219597 > [2] http://mail.openjdk.java.net/pipermail/nio-dev/2019-February/005900.html > [3] http://cr.openjdk.java.net/~bpb/8219597/webrev.00/ From brian.burkhalter at oracle.com Wed Feb 27 20:24:36 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Feb 2019 12:24:36 -0800 Subject: 8219597: (bf) Heap buffer state changes could provoke unexpected exceptions In-Reply-To: <9e400b53-23e1-0c3c-edec-e38018d3035a@oracle.com> References: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> <9e400b53-23e1-0c3c-edec-e38018d3035a@oracle.com> Message-ID: Hi Roger, > On Feb 27, 2019, at 12:10 PM, Roger Riggs wrote: > > The changes look fine. > > Alan's comments not withstanding, I'd be inclined to close it as WNF because it does not improve the concurrency situation and may further hide cases where the caller should be doing synchronization. With this change will be harder to observe that something is going wrong. I see your point. I?ll leave it open pending comment from Alan. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 27 21:48:59 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Feb 2019 13:48:59 -0800 Subject: 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes Message-ID: For the issue [1], please review the patch [2] which would replace the package-scope method java.nio.Buffer.checkBounds(offset,count,bound) with java.util.Objects.checkFromIndexSize(offset,count,bound) [3]. The latter method would provide more detail on the IOOBE if it should occur. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8219876 [2] http://cr.openjdk.java.net/~bpb/8219876/webrev.00/ [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Objects.html#checkFromIndexSize(int,int,int) From brian.burkhalter at oracle.com Thu Feb 28 01:31:05 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Feb 2019 17:31:05 -0800 Subject: 5071718: (bf) Add ByteBuffer.slice(int offset, int length) In-Reply-To: <5A30B625-7CDC-436E-A903-7FCA2B701597@oracle.com> References: <16BF3FA7-8D91-46B2-B92E-DD7C3DAB2327@oracle.com> <2dd85daa-e9e1-ac5c-ab57-5687969340d7@oracle.com> <9CA8B6D9-0B16-4BA7-B220-4D3FA7A6E9BB@oracle.com> <91a6fa13-3944-20fb-caff-67a206ade580@oracle.com> <29E0289F-9687-49C9-9015-9EABF897374C@oracle.com> <5A30B625-7CDC-436E-A903-7FCA2B701597@oracle.com> Message-ID: > On Feb 26, 2019, at 5:06 PM, Brian Burkhalter wrote: > >> On Feb 26, 2019, at 9:41 AM, Brian Burkhalter > wrote: >> >>> On Feb 26, 2019, at 9:32 AM, Alan Bateman > wrote: >>> >>> One small suggestion for the class description is to merge the two paragraphs on the slice methods into one to avoid the duplicate wording, it might be as simpler as "The slice() and slice(int,int) methods create a subsequence of a buffer; They leave the limit and position unchanged". >> >> Voila: >> >> *
  • The {@link #slice} and {@link #slice(int,int) slice(index,length)} >> * methods create a subsequence of a buffer: They leave the limit and the >> * position unchanged.

  • > > I created one more webrev [1] which includes the above change and adds some test coverage in java/nio/Buffer/StringCharBufferSliceTest.java which had been lacking. The CSR [1] was approved yesterday so I will plan to check this in tomorrow (Thursday) if there are no more comments. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8219608 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 28 01:55:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Feb 2019 17:55:27 -0800 Subject: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced In-Reply-To: References: <0C5F8BB5-D647-48F2-B093-EBF5C537F553@oracle.com> Message-ID: > On Feb 20, 2019, at 7:51 AM, Brian Burkhalter wrote: > >> On Feb 19, 2019, at 11:00 PM, Alan Bateman > wrote: >> >> On 20/02/2019 01:20, Brian Burkhalter wrote: >>> https://bugs.openjdk.java.net/browse/JDK-4833719 >>> >>> Provide covariant return type overrides for asReadOnlyBuffer(), compact(), duplicate(), and slice() [1]. If desirable, such overrides could also be provided for the bulk get() methods and the put*() methods. >>> >> I don't have cycles to think about this one right now but I suspect this will require study to figure out if spec changes are needed. For example, we might have to clarify how force and loader should behave when invoked on a MBB that is a view or the result of a slice or duplicate. > > Good point. I can investigate. Given the age of this issue it?s not pressing. For a given page size, the pages mapped are determined by the buffer address and capacity only. These values are the same as in the parent for the buffers returned by asReadOnlyBuffer() and duplicate(). The method compact() returns ?this? so the same situation obtains in that case. The buffers returned by slice() and slice(index,length) however will have addresses {address + position(), address + index} and capacities {remaining(), length}, respectively. Consequently the ?addr? and ?len? values passed to the native methods, e.g., msync() and madvise(), could differ if force() or load() were invoked on a slice. So it does appear as if some specification verbiage would be needed to indicate that force() or load() invoked on a slice will cause writing or loading of only those pages that the slice overlaps. Would adding such verbiage to force() and load() be the appropriate change in the specification? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 28 07:57:38 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Feb 2019 07:57:38 +0000 Subject: 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes In-Reply-To: References: Message-ID: On 27/02/2019 21:48, Brian Burkhalter wrote: > For the issue [1], please review the patch [2] which would replace the package-scope method java.nio.Buffer.checkBounds(offset,count,bound) with java.util.Objects.checkFromIndexSize(offset,count,bound) [3]. The latter method would provide more detail on the IOOBE if it should occur. > I assume you'll run benchmarks and/or look at the generated code to make sure that the checks inline as expected. Otherwise looks good. -Alan. From brian.burkhalter at oracle.com Thu Feb 28 21:57:49 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 28 Feb 2019 13:57:49 -0800 Subject: 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes In-Reply-To: References: Message-ID: <6C0D81F3-A217-4C59-A9EB-B3EE1F70F9D3@oracle.com> > On Feb 27, 2019, at 11:57 PM, Alan Bateman wrote: > > I assume you'll run benchmarks and/or look at the generated code to make sure that the checks inline as expected. The benchmark output [1] shows a small improvement for a 1024-byte bulk get and a slight degradation for a 1-byte bulk get. The benchmark code is [2]. The disassembled classes [3] (from ?javap -c?) differ in the presence of a ?pop? for the new code containing Objects.checkFromIndexSize(). Thanks, Brian [1] Benchmark output [A] Before Benchmark Mode Cnt Score Error Units CheckBounds.bulkGet1 thrpt 5 183273461.428 ? 1139045.897 ops/s CheckBounds.bulkGet1024 thrpt 5 31629761.018 ? 214187.677 ops/s [B] After Benchmark Mode Cnt Score Error Units CheckBounds.bulkGet1 thrpt 5 177589604.771 ? 6174996.093 ops/s CheckBounds.bulkGet1024 thrpt 5 32749414.040 ? 336815.284 ops/s [2] Benchmark snippet public class CheckBounds { private static ByteBuffer buf = ByteBuffer.allocate(1024); private static byte[] arr = new byte[1024]; private static int count = 0; static { buf.put(0, (byte)42); }; @Benchmark public int bulkGet1() { buf.rewind(); buf.get(arr, 0, 1); return count++; } @Benchmark public int bulkGet1024() { buf.rewind(); buf.get(arr, 0, 1024); return count++; } } [3] Disassembled classes [A] Before public java.nio.ByteBuffer get(byte[], int, int); Code: 0: iload_2 1: iload_3 2: aload_1 3: arraylength 4: invokestatic #19 // Method checkBounds:(III)V 7: iload_3 8: aload_0 9: invokevirtual #20 // Method remaining:()I 12: if_icmple 23 [?] [B] After public java.nio.ByteBuffer get(byte[], int, int); Code: 0: iload_2 1: iload_3 2: aload_1 3: arraylength 4: invokestatic #19 // Method java/util/Objects.checkFromIndexSize:(III)I 7: pop 8: iload_3 9: aload_0 10: invokevirtual #20 // Method remaining:()I 13: if_icmple 24 [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: