[jdk11u-dev] RFR: 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully

[Sergey Nazarkin]

Thanks, Andrew! That sounds like a reason to not bother the community with the patch for jdk8.

> On Aug 6, 2021, at 12:33, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
> 
> On 8/5/21 8:15 PM, Sergey Nazarkin wrote:
>> The patch looks scary but in general it just adds a guard at the beginning of unsafe copy block. So a bunch of code just shifted right without single line modification.
>> 
>> We got a few reports from the users about JVM crash when they modify file being mapped. It was  definitely application issue but Unsafe contains protection for primitive types so it might be worth to have the same for copy operation.
> 
> Sure, I understand. However, the only thing this patch changes is that
> you get a Java stack trace instead of a VM dump. Your program exits,
> either way. So it really is just about being graceful.
> 
> The default response to enhancements in old releases is no, and there's
> a good reason for that.
> 
> We need to learn from experience. Take, for example, JDK-8267689. That
> was a fix for a rare and hard-to-provoke crash when accessing
> misaligned Unsafe memory. The backport patch looked reasonable enough,
> and was working fine on the head release, but it was wrong. In fact,
> the head release had a subtle but latent bug, which wasn't so latent
> in 8u. This bug was worse than the original bug that JDK-8267689 was
> supposed to fix.
> 
> I think we shouldn't risk regressions like that unless we actually
> need to.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671