[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551975#comment-16551975
]
Benedict edited comment on CASSANDRA-9608 at 7/22/18 11:22 PM:
---------------------------------------------------------------
I assume this is to handle e.g. the removal of Unsafe.monitorEnter/monitorExit?
A simple improvement to this would be to use a volatile \{{ReentrantLock}}
instead of a long thread id, that is allocated only on contention. This isn't
quite as cheap as Unsafe.monitorEnter/monitorExit, as the inflated lock is
never repurposed until flush.
If we wanted, we could probably implement a partially re-usable one, which
might be applicable elsewhere, or we could have a static ConcurrentMap<Key,
WaitQueue> to inflate only precisely when needed (though this will cost more
CPU/memory bandwidth and allocations).
Or we could implement some static helper methods to help us lock against a
property using a special inflated lock object, that can be used for
synchronisation until there is no contention, and the last owning thread sets
the property to null on completion. This is something I could rustle up fairly
quickly, so let me know if you want me to produce a utility class for this.
was (Author: benedict):
I assume this is to handle e.g. the removal of Unsafe.monitorEnter/monitorExit?
A simple improvement to this would be to use a volatile WaitQueue instead of a
long thread id, that is allocated only on contention, then used as any other
WaitQueue to manage waiting threads. This isn't quite as cheap as
Unsafe.monitorEnter/monitorExit, as the inflated lock is never repurposed until
flush. If we wanted, we could probably implement a partially re-usable one,
which might be applicable elsewhere, or we could have a static
ConcurrentMap<Key, WaitQueue> to inflate only precisely when needed (though
this will cost more CPU/memory bandwidth and allocations).
> Support Java 11
> ---------------
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - <dependency groupId="net.sourceforge.cobertura"
> artifactId="cobertura"/>
> + <dependency groupId="net.sourceforge.cobertura"
> artifactId="cobertura">
> + <exclusion groupId="com.sun" artifactId="tools"/>
> + </dependency>
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
