188

I'm hoping someone can provide some insight as to what's fundamentally different about the Java Virtual Machine that allows it to implement threads nicely without the need for a Global Interpreter Lock (GIL), while Python necessitates such an evil.

AgentLiquid
  • 3,632
  • 7
  • 26
  • 30

5 Answers5

230

Python (the language) doesn't need a GIL (which is why it can perfectly be implemented on JVM [Jython] and .NET [IronPython], and those implementations multithread freely). CPython (the popular implementation) has always used a GIL for ease of coding (esp. the coding of the garbage collection mechanisms) and of integration of non-thread-safe C-coded libraries (there used to be a ton of those around;-).

The Unladen Swallow project, among other ambitious goals, does plan a GIL-free virtual machine for Python -- to quote that site, "In addition, we intend to remove the GIL and fix the state of multithreading in Python. We believe this is possible through the implementation of a more sophisticated GC system, something like IBM's Recycler (Bacon et al, 2001)."

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • 7
    Alex, what about the old attempts to remove the GIL, wasn't there a ton of overhead with that (a factor of 2 is what I recall)? – Bartosz Radaczyński Jul 15 '09 at 13:57
  • 11
    Yes Bartosz, Greg Stein did measure that in 1999. Garbage collection by reference counting was the killer, forcing huge overhead of fine grained locking. That's why a more advanced GC is crucial there. – Alex Martelli Jul 15 '09 at 16:19
  • 82
    The Unladen Swallow team has given up on removing the GIL: http://code.google.com/p/unladen-swallow/wiki/ProjectPlan#Global_Interpreter_Lock – Seun Osewa Mar 20 '10 at 20:25
  • 1
    Alternatives to Unladen and CPython are PyPy, Jython, and IronPython. The latter two don't have a GIL, but using the multiprocessing module sidesteps the GIL and is safer anyway. – Cees Timmerman Mar 12 '12 at 11:30
56

The JVM (at least hotspot) does have a similar concept to the "GIL", it's just much finer in its lock granularity, most of this comes from the GC's in hotspot which are more advanced.

In CPython it's one big lock (probably not that true, but good enough for arguments sake), in the JVM it's more spread about with different concepts depending on where it is used.

Take a look at, for example, vm/runtime/safepoint.hpp in the hotspot code, which is effectively a barrier. Once at a safepoint the entire VM has stopped with regard to java code, much like the python VM stops at the GIL.

In the Java world such VM pausing events are known as "stop-the-world", at these points only native code that is bound to certain criteria is free running, the rest of the VM has been stopped.

Also the lack of a coarse lock in java makes JNI much more difficult to write, as the JVM makes less guarantees about its environment for FFI calls, one of the things that cpython makes fairly easy (although not as easy as using ctypes).

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
Greg Bowyer
  • 1,684
  • 13
  • 14
7

There is a comment down below in this blog post http://www.grouplens.org/node/244 that hints at the reason why it was so easy dispense with a GIL for IronPython or Jython, it is that CPython uses reference counting whereas the other 2 VMs have garbage collectors.

The exact mechanics of why this is so I don't get, but it does sounds like a plausible reason.

user235859
  • 1,174
  • 1
  • 10
  • 6
  • 5
    When you're promiscuously sharing objects between threads, working out when nobody has a reference to a particular object any more is moderately awkward. Reference counting with a global lock is one (expensive) way. A different way to solve it would have been to only let one thread at a time hold references to the object, which would make most activity be thread-local at a cost of making inter-thread communications more awkward. Personally, I think it's telling that HPC uses message-passing between processors and not shared memory, and that it does so for scalability reasons... – Donal Fellows Apr 12 '10 at 22:03
  • Hm, well, basically, there are 2 types of garbage collection: mark and sweep (or stop-and-cioy, or however your particular implementation of this approach is called) and ref counting. The JVM currently uses a combination of both IMHO (generational garbage collection). Thus Java should suffer from the same problems with syncing ref counters as python? – Michael Beer Apr 29 '21 at 18:57
2

In this link they have the following explanation:

... "Parts of the Interpreter aren't threadsafe, though mostly because making them all threadsafe by massive lock usage would slow single-threaded extremely (source). This seems to be related to the CPython garbage collector using reference counting (the JVM and CLR don't, and therefore don't need to lock/release a reference count every time). But even if someone thought of an acceptable solution and implemented it, third party libraries would still have the same problems."

Oliver Wilken
  • 2,654
  • 1
  • 24
  • 34
-2

Python lacks jit/aot and the time frame it was written at multithreaded processors didn't exist. Alternatively you could recompile everything in Julia lang which lacks GIL and gain some speed boost on your Python code. Also Jython kind of sucks it's slower than Cpython and Java. If you want to stick to Python consider using parallel plugins, you won't gain an instant speed boost but you can do parallel programming with the right plugin.

Jim
  • 9