Description
As I understand the code at e8e8862#diff-ac0a4639bfa0a500bff9ac99c66eaf68c7bcfd92e3b043495844ebe88792024cR38-R55 uses System.currenttime() for the timing of the calls.
However System.currentTimeMillis() should never be used for call timing - as it will not give you correct results.
currentTimeMills() will be affected by clock changes (as it represents wall clock) on the OS, this may be NTP adjusting the close (via a skew so timing runs faster than it real time), or a step adjustment in the case of periodic clock resync (without spreading the difference over a period).
So in the case of an abrupt clock jump forward the code could think that there had been a lot longer spent inside the function that actually occurred, causing incorrect interruptions of the deserialization.
The fix would be to switch to System.nanoTime() which is independent of wall clock and hence clock drift