Wouldn't it also break most Python code that uses threading? Currently, everything is implicitly synchronized thanks to the GIL, so in Java terms it's as if every variable is declared "volatile".
If the GIL is removed and variables are no longer volatile (i.e, changes are no longer made visible immediately to other threads) that seems like it would break a lot of code. On the other hand, keeping every variable volatile seems like it would be terrible for performance.
Maybe I'm missing some critical difference between Python and the JVM here?
The GILectomy project was able to maintain thread safety on refcounting while (mostly) preserving performance by basically using some clever flags in the refcount to signal specific lifetimes/ownership (simplification for brevity). So you have good performance when the thread owns a reference while preserving safety for shared objects.
The smaller problem is this does at a small amount of overhead even to single-threaded performance. The gilectomy project improved performance elsewhere so net performance is close to the same.
The bigger problem would be integrating this strategy with all the libraries that rely on existing GIL behavior.
If the GIL is removed and variables are no longer volatile (i.e, changes are no longer made visible immediately to other threads) that seems like it would break a lot of code. On the other hand, keeping every variable volatile seems like it would be terrible for performance.
Maybe I'm missing some critical difference between Python and the JVM here?