RFR: 8224974: Implement JEP 352

[Alan Bateman]

On 06/08/2019 09:09, Andrew Dinn wrote:
> :
> 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.
>
I don't think we need to be concerned with any of this at this time. The 
unmapper is run by the reference handler thread. Also the 
synchronization here is for the counters so not the same thing as doing 
a blocking I/O operation while holding a monitor. At some point we'll 
examine all the file I/O operations as some of these are candidates for 
managed blockers, others are candidates for alternative implementations 
- there are bigger issues to resolve first and we've been trying to 
avoid carrying too many changes due to the complexity and effort needed 
to keep them in sync with the main line.

-Alan