cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
Date Sun, 22 Jul 2018 23:23:00 GMT

    [ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message