On 8/6/19 7:09 PM, Andrew Dinn wrote:
Hello Dmitry,
On 06/08/2019 15:25, Dmitry Chuyko wrote:
One quick question about synchronization in unmappers. One of
preliminary steps for Loom was to replace monitor usage by j.u.c locks
for I/O to let fibers release carrier threads. For instance see
JDK-8222774. Does it make sense to do the same in your new unmappers code?
. . .
[1] https://bugs.openjdk.java.net/browse/JDK-8222774
The unmapper code is not strictly 'new' as regards its reliance on
synchronization. It merely follows and repeats the pattern employed in
the prior code that it has generalized (by splitting the original
Unmapper into two distinct flavours of subclass).
If this poses a problem for Loom then it is a separate issue form the
one this JEP addresses. I think you should raise a new issue for that
change (just as you would have had to do before this change). I am sure
Alan Bateman will be happy to consider your proposal. Indeed, I would be
happy to implement it given his approval -- or leave it to you to do so
if you prefer.
Agree, Loom has a long road to go. So I suppose such a change will be a
part of larger work in sun.nio, and I or one of my colleagues will be
happy to participate. Changes will probably be straightforward (e.g.
JDK-8222882) but this synchronization is not covered by regression tests
so I believe in this case you'll help to retry some of your ad-hoc
testing or maybe some application tests you know about.
-Dmitry
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
