Hi Andrew,
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?
-Dmitry
[1] https://bugs.openjdk.java.net/browse/JDK-8222774
On 8/6/19 4:57 PM, Andrew Dinn wrote:
On 06/08/2019 13:44, Aleksey Shipilev wrote:
Ah, that is exactly what I wanted. Good then, scratch the rest of my comments.
. . .
I thought that translating two separate (and statically bound) Unsafe calls,
hooking them up to
separate Unsafe leaf entries, and then suddenly going into a single StubRoutine
call with dynamic
argument that dispatches at runtime is a bit awkward. I would have expected it
to end up with two
separate StubRoutines as well. Again, I have no strong opinion about this.
Ok, thanks for clarifying. Inertia dictates I leave the stubs as is :-)
Yes, this looks cleaner. The declarations can be a bit less crowded:
static address data_cache_writeback() { return _data_cache_writeback; }
static address data_cache_writeback_sync() { return
_data_cache_writeback_sync; }
typedef void (*DataCacheWritebackStub)(void *);
static DataCacheWritebackStub DataCacheWriteback_stub() { return ...
typedef void (*DataCacheWritebackSyncStub)(bool);
static DataCacheWritebackSyncStub DataCacheWritebackSync_stub() { return ...
. . .
http://cr.openjdk.java.net/~adinn/8224974/webrev.11
Looks good.
Ok, I'll fold this and the other format errors you identified into the
next patch.
If I could please get a nod from Alan Bateman (and assuming I don't
receive further comments from other reviewers) I'll push that next patch.
Any more for any more ... ?
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
