The difference between JVM, CLR and C in regards to parallel and concurrent code is that they are built for those kind of workloads, and have a memory model proper, hence not needing a GIL.
I think they would have to here, to support native modules. Jython (and I believe IronPython, but don't quote me) does not support native CPython modules. CPython modules explicitly control the GIL, so if they are supported (as they are here), you can't really leave the GIL out without exposing potential thread safety issues.
CPython does not have a GIL Global Interpreter Lock GC Garbage Collection phase with --gil-disabled. GraalVM does have a GIL, like CPython without --gil-disabled.
How CPython accomplished nogil in their - the original and reference - fork is described in the topical linked PEP 703.
It's possible to have a language that doesn't have a GIL, which you implement Python in, but that Python implementation then has a GIL.
The point being that you can't say things like: Jython is written in Java so it doesn't have a GIL. CPython is written in C so doesn't have a GIL. And so on.