New Python proposal: "Abolish" the global interpreter lock GIL | CPython interpreter may become faster

Recently, developer Alex Waygood mentioned in the Python Foundation blog a major topic on the Python language at the Python Language Summit held just last week - "abolishing" the Python language's Global Interpreter Lock (GIL).

"Double-Edged Sword": CPython - Interpreter and Compiler

As we all know, the flexibility of the Python dynamic language is a "double-edged sword". This means that there can be different runtimes, such as Pyston, Cinder, MicroPython, pypypy, etc., which may support the entire language, specific versions or subsets. But if you're using Python, then you're probably running CPython.

CPython is the standard Python interpreter written in C, which also acts as a compiler, since its job is to compile Python code in bytecode form before the actual interpretation stage.

CPython has something called the Global Interpreter Lock (GIL) that can affect threaded code, i.e. only one thread can run in the interpreter at a time. Therefore, the GIL has always been seen as an inherent limitation of the language's development.

There have been proposals to address this issue before, such as moving performance critical parts to C or using multiple interpreters. But to meet the above expectations, the audience of interpreter users may expand. There are several alternatives, such as through dedicated JVM (Java Virtual Machine) and CLR (Common Language Runtime) solutions, but most of the existing solutions above have considerable drawbacks.

Therefore, based on the above background, the support voice of "Python without global interpreter lock" has gradually attracted attention.

Attempts to be repealed: how exactly the GIL got rid of

Until this Python language summit, Sam Gross, senior engineering director of Meta, raised the topic of "abolishing the GIL" in the theme of the "nogil" project.

It is reported that the proposal is based on the previous idea of abolishing the GIL in Python. Gross initially had problems with Python projects using 3rd party code and started thinking "without the GIL" how to make things thread safe.

As mentioned earlier, the global interpreter lock GIL can only run one thread in the interpreter at a time, so when you can guarantee that only one thread is running at a time, the program state may be easier to reason about. But without the GIL, reference counting, memory allocation, method resolution order caching, and garbage collection threads would be unsafe.

So, how to get rid of the GIL?

Sam Gross reportedly discussed this evolution earlier. Since CPython is "thread safe" by design, it relies on the GIL. To get rid of the GIL, first, a major change to the reference count is required.

In order to know if the garbage collector can free an object in memory, it counts all references to that object. Currently, reference counting is non-atomic, and changing all reference counting operations to atomic has a huge performance impact.

Sam Gross used a technique called "biased reference counting" in this proposal to obtain local and shared references. Local references can take advantage of non-atomic operations, and the owning thread combines local and shared references to keep track of ownership. This approach works well for single-threaded objects, or objects that are only used sparingly by a few threads.

There are several objects in the lifetime of the program, such as interpolated strings, True, False, and None, that can be marked as "immortal", reducing their reference counting overhead to zero. Objects are marked as "immortal" by utilizing the least significant bits in the reference count field. Objects that are frequently accessed but not guaranteed to be "immortal" have deferred reference counting, which means that the only reference counting required is when the reference is stored on the heap, a side effect of this change is that the object cannot be reclaimed immediately because the stack needs to be scanned for any remaining citations.

Sam Gross replaced the standard pymalloc memory allocator with mimalloc, a replacement for malloc that provides thread safety and performance. The benefit of this swap is that this allocator allows the runtime to look for GC-tracked objects without an explicit list. This is a significant performance gain, but it means you can't just swap another malloc-compatible allocator and expect the same thread safety as garbage collection and collection.

Python has not yet decided whether to remove the GIL

As to why the GIL was removed, the Python Foundation blog explained, "In order for Python to work effectively without the GIL, new locks must be added to most code to ensure that it remains thread-safe, but It can be very difficult to have new locks added to the code, as there can be significant slowdowns in some areas."

This time, Sam Gross' new proposal to "remove the GIL" appears to have been "warmly" welcomed by the rest of the Python core development team. Now, the main problem to be solved is how to implement such a huge change on CPython.

It is reported that the next version of CPython (or CPython 3.11) is expected to be released in October 2022. I don’t know if there will be a major update by then, but it is reported that developers especially hope to get higher performance and better performance through this update. Supported integrations that run in the context of a web browser.

Over the past period of time, developers have tried several times to do away with this technique in the standard implementation of CPython, as the GIL has hindered the development of the language. This time, the new proposal to "remove the GIL" has finally arrived. Although the Python official has not yet made a final decision on the implementation, everything is still worth looking forward to.