On Tue, 10 Jun 2025 07:14:06 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> Hello @mrserb, >> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would >> be invoked by the EDT, which would eliminate the race condition. >> I didn’t proceed with it initially because I saw in that file that this >> pattern is only used in the JNI function calls, so I wanted to preserve the >> existing coding style paradigm. >> However, if you agree, I can move forward with this proposal. >> I actually prefer this approach, as it carries a lower risk of deadlocks and >> performance degradation as the codebase evolves and becomes more complex. > >> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would >> be invoked by the EDT, which would eliminate the race condition. > > Looks like the UnlinkObjects and _GetScreenImOn is already executed under > the same lock: > - WComponentPeer.dispose->AwtObject::_Dispose()->Lock on > SyncCS->WM_AWT_DISPOSEPDATA->awt_Component.cpp.dispose()->UnlinkObjects() > - WWindowPeer.getScreenImOn()->SyncCall()->Lock on > SyncCS->AwtWindow._GetScreenImOn() > > I think the only thing you should do is to replace the usage of JNI_GET_PDATA > by the JNI_CHECK_PEER_GOTO and add a label "ret" at the end so default value > of "result" will be returned. check how the _SetFocusableWindow is implemented below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2137143608
