Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

On 4/05/2017 2:07 PM, Vyom Tewari wrote: Hi David, I will look into the issue. Thanks. I filed: https://bugs.openjdk.java.net/browse/JDK-8179602 as you probably saw. David Thanks, Vyom On Thursday 04 May 2017 06:29 AM, David Holmes wrote: please find the updated

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi David, I will look into the issue. Thanks, Vyom On Thursday 04 May 2017 06:29 AM, David Holmes wrote: please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html). This change is broken on 32-bit systems - JVM_Nanotime returns a jlong which is

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html). This change is broken on 32-bit systems - JVM_Nanotime returns a jlong which is always 64-bit, but the code uses long for the nanotimeout values, which will be 32-bit on 32-bit systems! This

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

pushed the code(http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7cdde79d6a46). Vyom On Friday 28 April 2017 03:26 AM, Langer, Christoph wrote: Hi Vyom, I’ve just got a small formatting remark about the order of includes: Generally I tried to follow the rule 1. Common os headers, 2.

RE: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi Vyom, I’ve just got a small formatting remark about the order of includes: Generally I tried to follow the rule 1. Common os headers, 2. Platform os headers, 3. Jvm/jdk headers, 4. JNI headers in my latest refactorings. So, to keep this up, can you move #include “jvm.h” in the line before

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi, Even i thought the same, pass nanosecond timeout to "NET_Timeout" but if you see the implementation it uses " *int poll(struct pollfd **/fds/*, nfds_t */nfds/*, int */timeout/*);* " where timeout is in millisecond so we have to do conversion anyway in loop if we pass timeout in NS. So

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hello, It looks to me like using nanoseconds in the NET_Timeout Timeout Parameter would remove quite a few conversions. Callsides mostly already have timeoutNanoseconds for calculating reminder. Gruss Bernd -- http://bernd.eckenfels.net From: net-dev

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

> On 27 Apr 2017, at 05:15, Vyom Tewari wrote: > > Hi, > > please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html). This looks ok to me Vyom, but I think you have misinterpreted my comment... >> ... >> 1)

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html). Thanks, Vyom On Tuesday 25 April 2017 07:34 PM, Thomas Stüfe wrote: Hi Chris, Vyom, I have preferences as expressed earlier, but no strong emotions. I can live with the fix as it is

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi Chris, Vyom, I have preferences as expressed earlier, but no strong emotions. I can live with the fix as it is now. Thanks all, and Kind Regards, Thomas On Tue, Apr 25, 2017 at 3:31 PM, Chris Hegarty wrote: > > On Tue, Apr 18, 2017 at 7:08 AM, Vyom Tewari

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

> On Tue, Apr 18, 2017 at 7:08 AM, Vyom Tewari wrote: > ... > > Thanks for review, please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.6/index.html) The changes mainly look good to me, just a few comments: 1)

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Can't you just keep a NET_Timeout using directly os::javaTimeNano()? Gruss Bernd -- http://bernd.eckenfels.net From: net-dev on behalf of Thomas Stüfe Sent: Monday, April 24, 2017 1:07:52 PM To: Vyom

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi Vyom, sorry for the late response, I had vacation. Thanks for taking my suggestions! Here some remarks: --- I looked a little bit closer into the question why JVM_LEAF is used to wrap simple little functions like JVM_NanoTime or JVM_CurrentTimeMillis (among others). There is no hard

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi Thomas, Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.6/index.html) i incorporated all the review comments. Regarding why JVM_NanoTime is defined JVM_LEAF i don't know much, but all the functions which are defined in jvm.h used some

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi Vyom, Thank you for fixing this! In addition to Rogers remarks: aix_close.c: Could you please also update the SAP copyright? style nit: +//nanoTimeout has to be >= 1 millisecond to iterate again. I thought we use old C style comments? Could you please leave a space between

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

On Wednesday 12 April 2017 11:05 PM, Vyom Tewari wrote: Hi Roger, thanks for review, please see my comment inline. Vyom On Wednesday 12 April 2017 08:17 PM, Roger Riggs wrote: Hi Vyom, Thanks for taking this on. I have a few comments and questions. In aix_close.c line 547 The code

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi Roger, thanks for review, please see my comment inline. Vyom On Wednesday 12 April 2017 08:17 PM, Roger Riggs wrote: Hi Vyom, Thanks for taking this on. I have a few comments and questions. In aix_close.c line 547 The code for if (nanoTimeout >= NSEC_PER_MSEC) seems ineffective.

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi Vyom, Thanks for taking this on. I have a few comments and questions. In aix_close.c line 547 The code for if (nanoTimeout >= NSEC_PER_MSEC) seems ineffective. The update of nanoTime at 549-550 ensures the timeout is > NSEC_PER_MSEC if it loops. On the first pass through the code if