RFR: 8224974: Implement JEP 352
Alan.Bateman at oracle.com
Wed Aug 7 10:21:31 UTC 2019
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.
More information about the core-libs-dev