HackiNews

• lazystone
  > In theory, the whole AOT cache idea sounds like something that should only affect the class data and not perform any native compilation

  https://openjdk.org/jeps/544

  > Non-Goals

  > It is not a goal to support cross-compilation. Code compiled in a training run must run on the same CPU architecture, with the same set of features, in subsequent production runs.

  • florieger
    I wonder if this should trigger a warning (or even an error) at application startup whenever the CPU architectures differ.

    IMHO, that would be much better than running into crashes and having to figure out the cause yourself.

• deepsun
  > What would be needed is some sort of compatibility switch that disables all optional CPU features. Sure, you will get some reduced performance of the compiled code, but in exchange, a faster startup time.

  I think other AOT-compiled languages don't opt in for the lowest set of CPU features -- they just detect them at runtime and use whenever present, all in compiled machine code.

  • mikepurvis
    It's normally an opt-in thing I think, since you have to figure out how/where to trade off binary bloat vs the cost of dynamic dispatch:

    https://doc.rust-lang.org/beta/core/arch/#dynamic-cpu-featur...

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

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

• jiehong
  When AOT came to be, I kinda hoped for GraalVM's solution would make it relatively as-is to open jdk.

  Instead, this AOT feature is not very ergonomic to use at all, with too many pitfalls to be of broad use IMO.

• JMKH42
  I wonder if you could do the training run on install, so that each user gets a build tied to their specific cpu?

1 comment is not cached yet — read on Hacker News.