_old_dude_

The Inside Java podcast episode on AOT caching covers the issue in this segment:

https://youtu.be/U2j4bKgKr-s?t=3577

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).

Just here to say that Java as interruptible channels since the beginning of 2000.

You can interrupt a blocking IO operation with either interrupt() or close().

https://docs.oracle.com/en/java/javase/25/docs/api/java.base...

It's not hate, it's not wanted to be associated with:

see https://victorwynne.com/dhh/

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.

Yes, and let's not forget Stephen Elop's 'Burning Platform' Memo

https://www.wsj.com/articles/BL-TEB-2031

Parser generators are great in Python (Lark for me) so you can iterate fast and get a runtime spec of your grammar.

A hand-written recursive descent parser is something you do later when you start to industrialize your code, to get better error messages, make the parser incremental, etc.

Bison/ANTLR are code generators, they do not fit well in that model.

In C#, all instances have a class, so there is already a discriminant, the class itself.

In the article, the example with the switch works because it switches on the class of the instance.

In Scala 3, the inline keyword is part of the macro system.

When inline is used on a parameter, it instructs the compiler to inline the expression at the call site. If the expression is substantial, this creates considerable work for the JIT compiler.

Requesting inlining at the compiler level (as opposed to letting the JIT handle it) is risky unless you can guarantee that a later compiler phase will simplify the inlined code.

There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake.

There is a modern equivalent based on Linux criu.

https://github.com/CRaC/

Yes, the version in Java is clearly less elegant. Java has map+lambda and compareTo (<=>) but no tuple assignemnt and no splat.

    record AppVersion(int major, int minor, int patch) implements Comparable<AppVersion> {
      public static AppVersion of(String version) {
        var array = Arrays.copyOf(Arrays.stream(version.split("\\.")).mapToInt(Integer::parseInt).toArray(), 3);
        return new AppVersion(array[0], array[1], array[2]);
      }

      public int compareTo(AppVersion other) {
        return Comparator.comparingInt(AppVersion::major)
            .thenComparingInt(AppVersion::minor)
            .thenComparingInt(AppVersion::patch)
            .compare(this, other);
      }

      public String toString() {
        return "%d.%d.%d".formatted(major, minor, patch);
      }
    }

For the record (sorry), I believe C# uses the clone operation because records support inheritance.

For me, this is where lies the design flaw, trying to support both inheritance and be immutability at the same time.

> Libya was bombed primarily by France and then other NATO countries for no good reason

https://en.wikipedia.org/wiki/Alleged_Libyan_financing_in_th...

And AISQL is a thing ...

  https://quickstarts.snowflake.com/guide/getting-started-with-cortex-aisql/index.html

I'm glad i'm retired.

Java Almanac has a list of all features https://javaalmanac.io/features/

And the main page let you compare API versions https://javaalmanac.io/

> at least I know that the phone will be supported for at least 4 years

It's 4 (mid) to 7 years (flagship) for Samsung.

https://www.androidauthority.com/samsung-android-updates-114...

OOP is great for libraries but leads to overly complex codes for applications.

For a long time, Java was like, every classes is a library, i do not think it's a failure of OOP, it's a failure of Java.

But I'm optimistic, I choose to see recent additions like records and pattern matching has a step in the right direction.

I've just tried to change a field of an instance of a record using reflection, and it's not possible, even with setAccessible(true).

In Java, constants are declared as static final.

  static final Complex CONSTANT = new Complex(1, 2);

If you want a lazy initialized constant, you want a stable value

  static final StableValue<Complex> STABLE_VALUE = StableValue.of();

  Complex getLazyConstant() {
    return STABLE_VALUE.orElseGet(() -> new Complex(1, 2))
  }

If you want the fields of a constant to be constant too, Complex has to be declared has a record.

In JavaScript, a 'let' inside the initializer of a for loop is captured by value, all the others are captured by reference.

I think it's fair to call that semantics "implicit".

Parroting something i have heard at a Java conference several years ago, tail recursion remove stack frames but the security model is based on stack frames, so it has to be a JVM optimization, not a compiler optimization.

I've no idea if this fact still holds when the security manager will be removed.