RFR: 8176499: Remove MonocleTimer dependency on system time

[Kevin Rushforth]

On Wed, 19 Feb 2020 19:17:03 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%
> 
> @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:

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

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

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