Java’s Highly Scalable Low-Latency Garbage Collector : ZGC

Поделиться
HTML-код
  • Опубликовано: 5 ноя 2024

Комментарии • 15

  • @ignacemorel641
    @ignacemorel641 Год назад +34

    Java, the language that never stops improving.

    • @krellin
      @krellin 9 месяцев назад

      This is the JVM not java though

  • @sblantipodi
    @sblantipodi Год назад +2

    this GC is amazing, I tried it on my low latency app and it's amazing, leave alone the fact the defaults seems a lot better since this GC tends to release more resources to the OS more often.

  • @VisruthCV
    @VisruthCV Год назад +5

    👌💚💚💚💚💚
    Very informative presentation. Thanks 👍!

  • @con_sci
    @con_sci 8 месяцев назад

    does this have anything to do with project Leyden?

  • @dumdumdumdum8804
    @dumdumdumdum8804 Год назад +3

    When will generational zgc reach GA.

    • @billykorando
      @billykorando Год назад

      When it's ready 🙂
      Ultimately I could only provide speculation, that could soon prove incorrect. The most current information would be found on the ZGC dev mailing list: mail.openjdk.org/pipermail/zgc-dev

    • @dumdumdumdum8804
      @dumdumdumdum8804 Год назад

      @@billykorando Your Speculation will help, I am totally clueless about it and there isn't much about it in the mailing list of its readiness for GA.

    • @billykorando
      @billykorando Год назад

      @@dumdumdumdum8804 JEP for generational ZGC has just been moved to draft status openjdk.org/jeps/439
      So that’s a good indication it will be in JDK 21, no promises though 🙂

    • @dumdumdumdum8804
      @dumdumdumdum8804 Год назад

      @@billykorando Thats pretty cool it is already in candidate status. I wonder what will happen to our microservices will it also reduce memory footprint to 1/4 as in the case of Cassandra. We use grpc and kafka most of our services consume 300 MB to 500 MB of memory, with generational zgc i expect it to be 75 to 125MB which will allow us to deploy more services or increase the number of pods for the same service.
      generational ZGC + lilliput + Leyden -> Huge cost saving.

    • @dumdumdumdum8804
      @dumdumdumdum8804 Год назад

      @@billykorando For Valhalla I think we have to do code changes to take advantage of dense memory layouts, may be if valhalla is retrofitted into autoboxing then probably we will enjoy good performance out of the box by just switching to latest version of jdk.

  • @prdoyle
    @prdoyle Год назад +1

    I think you don't want a tesseract. You want a k-simplex. 🤓

  • @berndeckenfels
    @berndeckenfels Год назад +2

    Still in Shenadoah denial? ,)

    • @krellin
      @krellin 9 месяцев назад

      totally, though on paper zgc should be better than shenan
      1. it uses totally free bits of available memory in references, while shenon uses entire extra word per object (though i might be wrong seems from 2.0 it doesnt anymore)
      2. it uses only load barriers vs shenon using both load and store gc barriers...
      Either way we only need to care about 2 GCs to choose from now on... and they are both free.