On Thu, 31 Aug 2023 22:48:30 GMT, Aleksei Efimov <aefi...@openjdk.org> wrote:
> The change proposed in this PR improves the behavior of the JDK JNDI/LDAP > provider when running in a virtual thread. Currently, when an LDAP operation > is performed from a virtual thread context a pinned carrier thread is > detected: > > Thread[#29,ForkJoinPool-1-worker-1,5,CarrierThreads] > java.naming/com.sun.jndi.ldap.Connection.read > reply(Connection.java:444) <== monitors:1 > > java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:369) <== > monitors:1 > > java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:196) > <== monitors:1 > java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2896) <== > monitors:1 > > To fix that monitor usages are replaced with `j.u.c` locks. All synchronized > blocks/methods have been replaced with locks even if it is only guarding > memory access - the motivation behind such a decision was to avoid an > analysis of scenarios where a mix of monitors and `j.u.c` locks is used. > > There are three types of mechanical changes done in this PR: > > 1. Classes with `synchronized` blocks or `synchronized` methods have been > updated to include a new `ReentrantLock` field. These new fields are used to > replace `synchronized` blocks/methods. > 1. classes that use notify/wait on object monitor have been updated to use > `ReentrantLock.Condition`s signal/await. > 1. if one class `synchronized` on an instance of another class - the > `ReentrantLock` added in item (1) was made a package-protected to give access > to another class. > > With the proposed changes pinned carrier threads are no longer detected > during execution of LDAP operations. > > Testing: `jdk-tier1` to `jdk-tier3`, other `jndi/ldap` regression and JCK > naming tests show no failures. Look reasonable to me. If tier2 and all jndi tests are still passing, I'm good with it. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15526#pullrequestreview-1617680805
