RFR: 8224974: Implement JEP 352

Andrew Dinn adinn at redhat.com
Tue Aug 6 16:09:46 UTC 2019


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.

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


More information about the core-libs-dev mailing list