_old_dude_

If you want V8 like optimizations, you have to introduce a strict mode.

Python interpreter is known to leak its implementation (__class_ modification after creation, monkey patching with __getattr__, sys._getframe, eval/exec, deterministic call to __del__, no proper python API for libraries, etc.)

You have to plug all of those holes before having a chance to get a decent JIT. Otherwise it will be just another JIT attempt, like Psyco, Unladen Swallow, Pyston.

Assuming “groups” are mainly about grouped invalidation, I agree, Path Borrowing is the better name, since it describes the core idea rather than the implementation mechanism.

All Java GCs are generational collectors, they reduce the marking time (for young collection) by tracking if there is a reference from the old generation to the new generation.

The benchmark creates an array in the old generation (by being big enough) and stores an object (allocated in the new generation). This triggers the GC barrier for every writes. Something rare in real application.

The G1 barrier before Java 26 is slow because:

- the GC barrier and some GC threads do concurrent operations on the same memory zone (the card table)

- the barrier is big (a lot of assembler instructions) so it also troubles the loop unrolling optimization performed by JITs

Parallel GC has a simple barrier and do not care about latency (no GC check inside the loop).

The barrier implementation of G1GC was changed in Java 26, so update your Java runtime version and move on.

Nice article.

I think this is similar to the way Kotlin implements coroutine.

I believe Kotlin goes to the extra miles to also capture parts of the stack frames when creating the Continuation object so even when the runtime resume the continuation, the exceptions thrown later get the "correct" stack trace (not the one that shows that you come from a call through a MethodHandle).

For me, the difference is that if methods are inlined, the compiler is still required to do a copy for structs but not for value classes.

I do not know how this is called.

I think pass by copy is a consequence of being modifiable.

The other solution is to stack allocate and pass a pointer but as i said, unlike in C#, i do not think it's possible to do that in Java.

In Go, you can stack allocate but when you send a pointer (that escapes), the compiler will heap allocate the object.

The article has a section about that.

For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value.

I do not think you can do stack allocation in Java.

The usual GC tradeoff is between memory and CPU performance. If you set the memory max high, the GC will run less often, you get less pause time.

So I do not understand why it's a surprise that minimizing the pause time requires more memory. Is it because there is no knob to set either the max pause time or the max memory ?

I agree. And the next section is very clear that they want to kill the project.

  > For example, rather than proposing one single concrete JIT implementation,
  > it may make more sense for the PEP to describe a JIT infrastructure that
  > can support multiple implementation strategies.
  > Since many different and promising JIT tracing approaches continue to be proposed,
  > we believe the infrastructure should make it easy to experiment with and evaluate
  > those approaches within CPython rather than be highly coupled with a single strategy.

Allowing multiple strategies is far harder and as far as I know, JIT tracing is still unproven.

You need more than that for the example with setTimeout(). It requires to be able to freeze the stack and then go back later.

You need stackful coroutine (like goroutine) for that.

If you do not block 3rd party harness, people will discover that a good harness is more important than a good model.