8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards #117
Conversation
|
👋 Welcome back dellgreen! A progress list of the required criteria for merging this PR into |
|
@kevinrushforth apologies for previous, my local repos seem to be messed up when i changed remotes from old javafx github repo to new one, as that rogue commit didnt exist my side for some reason. looks like its fixed now |
|
I don't see any stray commits, so it looks like your branch is based off of master correctly. One thing I would ask you to change is that the title of this PR should exactly match the title of the JBS bug. So can you change it to: |
|
Seems a simple enough fix. Probably @johanvos can review it. |
dellgreen
changed the title
apologies, all done |
|
I have a question about the scheduling of the task: Now I think that scheduling at fixed rate would be the correct way as we want to reach 60 pulses per second. But my question is: Can this lead to problems if the work done per pulse takes longer than 16ms? The scheduleAtFixedRate does queue subsequent executions if the previous task takes too long. Couldn't this lead to an task queue overflow if the system is overloaded? Do we need to add protection for that scenario? |
|
I may be wrong, but looking at the source code for both java.util.Timer.java and ScheduledThreadPoolExecutor.java, they both appear to grow their respective queues if needs be. So i don't think the proposed solution is any worse in that respect. |
|
Ok. Thanks for the clarification. |
|
@dellgreen This change now passes all automated pre-integration checks. When the change also fulfills all project specific requirements, type
Since the source branch of this PR was last updated there have been 78 commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge As you are not a known OpenJDK Author, an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@johanvos) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
|
/integrate |
|
@dellgreen |
|
@dellgreen The |
|
@kevinrushforth ok, thank you for the feedback |
|
/sponsor |
openjdk
bot
added
integrated
|
@johanvos @dellgreen The following commits have been pushed to master since your change was applied:
Your commit was automatically rebased without conflicts. Pushed as commit 1cae6a8. |
https://bugs.openjdk.java.net/browse/JDK-8176499
This pull request fixes a long standing issue in the MonocleTimer class whereby it has a dependency on the java.uti.Timer class which is dependent on system time and can cause UI freezes for seconds/minutes/hours/days/years dependent upon how far back in time the system clock is set by either a user manually or NTP. This looks like it is because the Timer class will wait for (executionTime - currentTime) before proceeding if a task hasn't fired yet.
https://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/util/Timer.java#l553
For a long running embedded device with a UI like IOT devices this is pretty disastrous.
We recently re-discovered this issue whilst testing such a device before going into production.
The MonocleTimer class is used by MonocleApplication and QuantumToolkit class to create its pulseTimer for emebdded systems and sets it up to fire periodically inline with the requested pulse frequency which by default is 60Hz resulting in a pulse interval of 16ms.
It is well documented that for implementations that wish to measure elapsed time ScheduledThreadPoolExecutor should be used as a replacement for java.util.Timer class.
Java Concurrency In Practice:
https://pdfs.semanticscholar.org/3650/4bc31d3b2c5c00e5bfee28ffc5d403cc8edd.pdf (page 77)
"The Timer facility manages the execution of deferred ("run this task in 100 ms") and periodic ("run this task every 10ms") tasks. However, Timer has some drawbacks, and ScheduledThreadPoolExecutor should be thought of as its replacement."
With the original implementation, if I set the date.time back 8 years for example the UI freezes up indefinitely (I cant wait 8 years). Repeating the same test with the proposed implementation has no affect on the UI and it runs as normal.
The proposed solution has been tested on an Arm iMX6 board.
Whist testing in isolation the MonocleTimer class with no work to do on each pulse, it looks like the change from Timer class to ScheduledThreadPoolExecutor also has brought with it a greater accuracy of when the pulses are fired.
The following results were observed when running MonocleTimer at 60Hz for 1 minute. It appears that we get a higher frequency of pulses hitting the 16ms mark with the replacement solution
x86-64 linux desktop:
---- Timer class ----
NumSamples: 3599
Mean: 16.230063906640734
StdDev: 0.45021901536403147
Median: 16
Mode: 16, freq: 2714, perc: 75.40983606557377%
---- Scheduler class ----
NumSamples: 3599
Mean: 16.0
StdDev: 0.0
Median: 16
Mode: 16, freq: 3599, perc: 100.0%
Arm linux iMX6:
---- Timer class ----
NumSamples: 3599
Mean: 16.182272853570435
StdDev: 0.4224950723394174
Median: 16
Mode: 16, freq: 2837, perc: 78.82745207001946%
---- Scheduler class ----
NumSamples: 3599
Mean: 15.995554320644624
StdDev: 0.3666906549602725
Median: 16
Mode: 16, freq: 3468, perc: 96.3601000277855%
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jfx pull/117/head:pull/117$ git checkout pull/117