RFR: 8224974: Implement JEP 352

[Dmitry Chuyko]

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