Hello, There are a few places where a synchronized method is freed up w/o new lock, which is generally a good thing but I wonder if there is a justification available why it is no problem (DTLSInputRecord vs. DTLSOutputRecord).
Is the DCL In EphemeralKepair Safe, I am not sure how arrays and not beeing volatile mixes? Is there an undesired spacing change in a SSlEngineImpl.java and SSLSocketOutputRecord.java (or is this a webrev artifact)? The additional use of the SSLEngineOutputRecord lock in close, is this fine? (It could block the close() if the lock is held) >From a commit description point of few removing of unneeded Synchronisation or >replacing them with a holder pattern and introducing DCL is a very positive >thing which should be mentioned in the description I think? And an aside, is this a general direction the JCL has to go for loom to remove synchronized methods and blocks? Those ex synchronized methods look a lot more ugly with the try/final (especially since there is no TWR autoclose) and the additional locks also increase the footprint. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev <[email protected]> im Auftrag von Xuelei Fan <[email protected]> Gesendet: Mittwoch, April 3, 2019 6:48 AM An: [email protected]; Alan Bateman Betreff: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/ To benefits from with Fibers [1], there is a need to use explicit locks, java.util.concurrent.locks, for synchronization in JSSE and the SunJSSE provider. Most of the update is replacing synchronized blocks with java.util.concurrent.locks.ReentrantLock locking/unlocking. Thanks, Xuelei [1]: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
