Nikita Koval

At @jetbrains, we not only provide top-notch programming tools but also conduct cutting-edge pragmatic research. Recently, we presented a new channel algorithm in @kotlin coroutines and the fastest concurrent queue at @PPoPPConf — a top-tier conference on parallel programming. /1

Since then, I often don’t need to launch the whole project locally just to make a review. Instead, I get evidence of how the solution behaves with a simple prompt. For me, this already saves time and reduces context switching. Maybe useful for your projects too.

For many PRs, review means: launch the IDE plugin, connect to Spring PetClinic, add breakpoints, trigger requests, open breakpoint hits, and inspect objects. That’s boring but important. So I asked AI to do it on a virtual display, from a plain-English prompt. Demo below 👇

I recently moved to an internal startup incubator at JetBrains to build a safe debugger for production systems: appglass.org The project often requires a complex setup, so I started using AI not only for development, but also for reviewing, asking it to record demos.

Happy to make my small contribution with a custom read-write mutex for coroutines here 🙌

On my way to ICFP/SPLASH! Our team is giving two tutorials this Sunday — one on Lincheck and another on algorithms in Kotlin Coroutines. Check the schedule and join us in person or online 🤗 2025.splashcon.org/track/icfp-spl…

Reviewing PPoPP papers today — happy to see many strong submissions on concurrency. Remember PPoPP two years ago, the focus was on parallel systems. It’s great to see the shift! PPoPP has a rich history of concurrent algorithms, and I hope it remains a key venue for them.

@asm0di0 @tagir_valeev @asm0di0 Hmm... I haven't heard about that.

@nkoval_ @tagir_valeev You know some time ago JetBrains acquired the company which did exactly that?

Last week, there was an internal hackathon at JetBrains. Look at what our team has prototyped in just 48 hours: a Time-Traveling Debugger for IntelliJ IDEA! 🚀 Hope it will become a bigger project🤞

@tsitelov @AndreyPechkurov @forked_franz This is from the source code (but not a part of the documentation).

@nkoval_ @AndreyPechkurov @forked_franz Could you please point out the "specs fix" for the issue? I mean that j.u.c package doc states HB warranties for all concurrent collections and I failed to find any "exclusions" for CLDeque except for size and iterators.

ConcurrentLinkedDeque in Java is non-linearizable. Here is the Lincheck test that reveals the issue and explains the root cause of the problem. I've also put this code on GitHub: github.com/ndkoval/concur… (Thread)

@AndreyPechkurov @forked_franz @tsitelov Yes, the issue was “fixed” by relaxing the behavior in the documentation (after two attempts to fix the implementation), which is quite pragmatic, and I fully support the decision. However, it would be much better not to have a non-linearizable implementation in the first place.

@tsitelov @nkoval_ The issue was reported a long time ago: bugs.openjdk.org/browse/JDK-825… > Not strictly a bug - there's no such guarantee in the spec.

With Lincheck, we easily investigated why ConcurrentLinkedDeque is incorrect without diving into the source code. Check the GitHub repo with this test to reproduce the bug and play with Lincheck! github.com/ndkoval/concur…

Finally, the algorithm tries to unlink the extracted node from the linked list, but this part does not affect correctness.