We live in the post "free lunch is over" era. Published in 2005, "The Free Lunch Is Over. A Fundamental Turn Toward Concurrency in Software" Herb Sutter's article was a forewarning that things are about to grow more complicated and unpleasant and that no-one is safe unless you don't give a f... about your work, which is fine.
Concurrency is hard. However, without it, our multicore systems would be worthless. We have reached the CPU clock limit years ago.
There is still space for more and more transistors, so we cram extra cores, more caches, write-combining buffers, point-to-point processor interconnect, and other fancy techniques
to squeeze every nanosecond out of silicone.
On the other hand, we programmers take pride in being lazy. We don't want to think about memory ordering, fences, memory models, cache coherence, false sharing,
and all these low-level implementation details. One way is to make all things immutable and just forget about them.
What if there was a different way? Do you want to eat cake and have cake? Can we have mutable objects and be able to prove that your program is data race and deadlock-free?
Welcome to the object and reference capability model. In this talk, I will explain the capability model, destructive reads, how to consume objects, and recover references.
After this quick and dirty introduction, I will show you how we could implement this model in the JVM, without touching a single line of JVM code,
just messing with annotation processing, bytecode, CFG (control flow) and DFG (data flow) graphs. I hope at the end we will all shake our heads in awe
and ask this simple question, 'But why?'