[
https://issues.apache.org/jira/browse/CASSANDRA-20176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17915861#comment-17915861
]
Dmitry Konstantinov commented on CASSANDRA-20176:
-------------------------------------------------
{quote}
Not sure how much time and appetite you have for experimentation, but I'd be
very interested to see the non-SEP executor running on virtual threads in JDK22
(since prior have a synchronized deadlock limitation with vthreads). We have a
ticket w/JDK21 support in CASSANDRA-18831;
{quote}
Hi [~jmckenzie], thank you for the suggestion. Appetite - yes, definitely; time
- as always is a limited resource :). I am already watching for CASSANDRA-18831
closely from another perspective: to get ZGC (as a generational low-pause
collector) available. Regarding virtual threads I think we can create a
separate story for an initial analysis/prototyping: it is definitely an
interesting topic and I am ready to apply some efforts but cannot promise to
move fast..
Currently my primary focus is on squeezing more from the current architecture
by applying efforts to optimize hot paths and to eliminate local bottlenecks:
we still have a lot of such places to improve. For example: a Java 11/17
alternative to virtual threads can be just a completable future-based logic for
coordinator part where we wait for replicas to complete their reads/writes and
send an answer back to a client, based on on profiles/flamegraphs this
park/unpark is quite expensive.
> Reduce memory allocation in SEP Worker spin wait logic
> ------------------------------------------------------
>
> Key: CASSANDRA-20176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20176
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Attachments: image-2025-01-01-13-14-02-562.png,
> image-2025-01-01-13-15-16-767.png, ttop_disabled_sep.txt, ttop_enabled_sep.txt
>
>
> There is a visible memory allocation within spin waiting logic in SEP
> Executor: org.apache.cassandra.concurrent.SEPWorker#doWaitSpin for some
> workloads. For example it is observed for a writing test described in
> CASSANDRA-20165 where ~8.5% of total allocations are from this logic:
> !image-2025-01-01-13-14-02-562.png|width=570!
> !image-2025-01-01-13-15-16-767.png|width=570!
> The idea of this parking is to avoid unpark signalling costs. The logic
> selects a random time period to park a thread by LockSupport.parkNanos and
> put the thread into a ConcurrentSkipListMap using wake up time as a key, so
> the map is used as a concurrent priority queue. Once the parking is finished
> - the thread removes itself from the map. When we neede to schedule a task -
> we take a spinning thread with the smallest wake up time from the map.
> We can try to implement another algorithm for this logic without memory
> allocation overheads, for example based on a Timing Wheel data structure.
> Note: it also makes sense to check granularity of actual parking time
> (https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
