(10) (M) RFR: 8174231: Factor out and share PlatformEvent and Parker code for POSIX systems (original) (raw)
David Holmes david.holmes at oracle.com
Fri May 19 09:07:46 UTC 2017
- Previous message: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and Parker code for POSIX systems
- Next message: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and Parker code for POSIX systems
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Robbin,
Thanks for looking at this.
On 19/05/2017 6:36 PM, Robbin Ehn wrote:
Hi David,
On 05/18/2017 08:25 AM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
webrevs: Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/ hotspot: http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/ I like this, with neg delta of 700 loc, nice! It's hard to see if you broken anything, since you combined 4 separate implementation into 1.
Well not really. As I said this is basically a cleaned up version of the Linux code. The BSD and AIX versions were already based on earlier versions of the Linux code, minus the proper handling of CLOCK_MONOTONIC and absolute timeouts.
I guess you have tested this proper?
Only JPRT so far. I should have mentioned that I'm not expecting this to be reviewed in pushed within a couple of days, so some refinements and continual testing will occur.
What stands out in osposix.cpp is the static void toabstime(timespec* abstime, jlong timeout, bool isAbsolute)
The ifdef scopes of SUPPORTSCLOCKMONOTONIC is large and calculations are repeated 3 times.
They have to be as there are three cases:
- Relative wait using CLOCK_MONOTONIC
- Relative wait using gettimeofday()
- Absolute wait using gettimeofday()
Please consider something like:
#ifdef SUPPORTSCLOCKMONOTONIC if (useclockmonotoniccondattr && !isAbsolute) { // Why aren't we using this when not isAbsolute is set? // I suggest removing that check from this if and use monotonic for that also.
Absolute waits have to be based on wall-clock time and follow any adjustments made to wall clock time. In contrast relative waits should never be affected by wall-clock time adjustments hence the use of CLOCK_MONOTONIC when available.
In Java the relative timed-waits are:
- Thread.sleep(ms)
- Object.wait(ms)/wait(ms,ns)
- LockSupport.parkNanos(ns) (and all the j.u.c blocking methods built on top of it)
While the only absolute timed-wait we have is the LockSupport.parkUntil method(s).
Hope that clarifies things.
Thanks, David
struct timespec now; int status = clockgettime(CLOCKMONOTONIC, &now); assertstatus(status == 0, status, "clockgettime"); calctime(abstime, timeout, isAbsolute, now.tvsec, now.tvnsec, NANOUNITS); } else { #else { #endif struct timeval now; int status = gettimeofday(&now, NULL); assert(status == 0, "gettimeofday"); calctime(abstime, timeout, isAbsolute, now.tvsec, now.tvusec, MICROUNITS); } #endif
Thanks for fixing this! /Robbin
- Previous message: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and Parker code for POSIX systems
- Next message: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and Parker code for POSIX systems
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]