On Wed, 19 Feb 2020 19:14:08 GMT, Dell Green <github.com+12861109+dellgr...@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 ------------- PR: https://git.openjdk.java.net/jfx/pull/117
