RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE
Bernd Eckenfels
ecki at zusammenkunft.net
Wed Apr 3 09:32:38 UTC 2019
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 <security-dev-bounces at openjdk.java.net> im Auftrag von Xuelei Fan <xuelei.fan at oracle.com>
Gesendet: Mittwoch, April 3, 2019 6:48 AM
An: security-dev at openjdk.java.net; 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190403/0d8be4b0/attachment.htm>
More information about the security-dev
mailing list