The handling for putFromLoads (coming without transaction start timestamp) was incorrect. This manifested as storing the value with expirable metadata as the code was assuming that it stores only an empty VersionedEntry. The putFromLoads were then expired from the cache too soon, causing less cache hits => inferior performance.
However, there was more severe problem related to this: Since the putFromLoad record did not have any timestamp associated, after arriving to a cache containing evicted record (empty VersionedEntry, without version), the putFromLoad was applied. With asynchronous putFromLoads, the value could be already stale and without checking timestamp that could result in storing such stale value. This is not that bad in nonstrict mode caches, since stale entries are acceptable (the value was stored as mortal - expired after 1 minute by default), but given that it does not provide much performance benefit, it's not acceptable behaviour.
, does this affect 5.0 and 5.1?
Not sure, but rather not; the scenario here is closely related to which was not backported yet (and yes, I know about your trouble with the backport and I intend to handle it, but haven't managed to get myself to it).