[ https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552702#comment-16552702 ]
Benedict commented on CASSANDRA-9608: ------------------------------------- {quote}I was racking my brain to see if there's an alternative to allocating an object on-demand {quote} Well, it would be possible to implement our own variant of the JDK's internal locking, which has a shared pool of locks that are allocated to a given object on demand, but this would have to be done in unsafe territory. This would be quite possible too, but it's more involved. I would be happy to have a crack at it, but that's probably several days' work instead of a couple of hours. {quote}A {{ReentrantLock}} would need to be allocated and used "pessimistically" up-front - i.e. for every instance of {{AtomicBTreePartition}}, so some non-negligible overhead to what we have now. {quote} Why do you suppose this to be the case? It only needs to be allocated on demand, but then must persist after it has been allocated. The current proposals have the following characteristics (which are approximately true; I haven't been absolutely thorough, particularly for ReentrantLock, and have fudged some context-specific things): ||Operation||Simple Condition||ReentrantLock||Inflating Lock 1||Inflating Lock 2|| |Quiescent memory overhead (after contention)|0 bytes|60 bytes|0 bytes|32-bytes| |First Uncontended lock()|1x CAS 24-byte allocation|60-byte allocation|1x CAS 32-byte allocation (or 48-byte, depending on choices)|1x CAS 64-byte allocation (or 80-byte, depending on choices)| |Future Uncontended lock()|1x CAS 24-byte allocation|1x CAS|1x CAS 32-byte allocation|1x CAS 32-byte allocation| |First Contended lock()|2x CAS 112-byte allocation|3x CAS 32-byte allocation|1x CAS 32-byte allocation|1x CAS 32-byte allocation| |Future Contended lock()|1.5x CAS (only hop tail once per two additions) 64-byte allocation|3x CAS 32-byte allocation|1x CAS 32-byte allocation|1x CAS 32-byte allocation| |Release|2x volatile write 1x volatile write + 1x unpark *_per_* waiting thread _If > 1 waiting thread: *will incur all*_ _*contended lock() costs again*_|2x volatile write 1x CAS + 1x unpark *_if_* waiting thread|1x volatile write 1x volatile write + 1x unpark *_if_* waiting thread 1x CAS if no waiting threads (to deallocate safely)|1x volatile write 1x volatile write + 1x unpark *_if_* waiting thread| There are other possible variants with different tradeoffs, for instance reducing allocation costs for uncontended lock() in option (2) at possible modest increase in CPU and implementation complexity. Again, I disclaim any modest inaccuracies as didn't want to spend too long putting this together. > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org