RFR: 8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards

[Johan Vos]

On Wed, 19 Feb 2020 19:14:08 GMT, Dell Green <github.com+12861109+dellgreen at openjdk.org> wrote:

> 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%

Marked as reviewed by jvos (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/117