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
