<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 2, 2022 at 7:43 PM Stuart Marks <<a href="mailto:smarks@openjdk.org">smarks@openjdk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">...<br>
Setting this aside, it does seem like all uses of a cleanable object need to have a try/finally statement, with at least an RF in the finally clause. Is there any evidence that shows that this construct isn't needed?<br></blockquote><div>I think the reachabilityFence is clearly needed with current implementations, though their omission is hard to test for, since the failures tend to only occur with unlikely schedules. But those schedules clearly exist. And fixing implementations to avoid that by unconditionally preserving references is problematic, especially given that bytecode tends to hide scopes. (Back during Java memory model discussions, there was also an argument that this would cause us to pay everywhere for a rarely used feature. I believe the "rarely used" part less and less. On the other hand, I also now tend to view a percent or two performance difference as more significant than back then, so maybe that overall argument still applies.)</div><div><br></div><div>I would also guess that the try-finally is required by some current optimizations. But that's more based on an argument that such optimizations exist, so somebody must have implemented them, rather than anything more concrete.</div><div><br></div><div>Hans</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-------------<br>
<br>
PR: <a href="https://git.openjdk.org/jdk/pull/8311" rel="noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/8311</a><br>
</blockquote></div></div>