RFR: 8343877: Test AsyncClose.java intermittent fails - Socket.getInputStream().read() wasn't preempted [v2]

[Mark Sheppard]

On Thu, 14 Nov 2024 12:42:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Mark,
> 
> > is it the case that a try-with-resource, and the implicit final declaration of s2, will maintain a strongly reachable reference ?
> > Rather than having to declare s2 as a final member variable of Socket_getInputStream_read, as done with the reader socket s, or using a ReachabilityFence to maintain an extant reference.
> 
> The use (or non-use) of `final` doesn't play a role here. The use of try-with-resources for the `s2` `Socket` instance (the one which was being cleaned up by the `Cleaner`) is what enforces the strong reachability. The JLS (linked in the PR description) explains how the try-with-resources is implemented - specifically, the compiler introduces bytecode to have an explicit call to `s2.close()` at the end of that try-with-resources block (this can be checked by running `javap` against these updated classes). The presence of that `s2.close()` call is what enforces the reachability of `s2`.
> 
> > I terms of "cleanliness" the listener ServerSocket is implicitly released
> 
> I have now updated the PR to use a try-with-resources for the `ServerSocket` too. The tests continue to pass with these changes.

Cheers JP, thanks for that feedback and for ServerSocket suggestion
yes, I appreciate and understand the implicit additions which come with try-with-resource and the autoclose. As such, I was just confirming that as s2 is a local variable, this is is sufficient to extend scope of a strongly reachable reference.

in any case ... it's all good

"big shout out" to @djelinski for some insightful observation during this issue investigation

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22093#issuecomment-2476456402