(comments)

原始链接: https://news.ycombinator.com/item?id=44059953

JEP 519 promotes Compact Object Headers in OpenJDK from experimental to a product feature, aiming for memory footprint reduction and performance improvements. Previous experimental versions (JEP 450) have been tested extensively at Oracle and Amazon, demonstrating positive performance results, including a 10% improvement in JSON parsing. Despite the promising results, Compact Object Headers won't be enabled by default. This cautious approach is typical in the JVM world due to concerns about potential compatibility issues. Enabling it still requires specific flags. One commenter inquired about its impact on GraalVM Native Image, but another clarified it primarily affects the HotSpot JVM, and Native Image likely already uses smaller headers. Making it non-experimental simply means it is ready for product use, not that it will become the default behavior.

相关文章
  • JEP 519:紧凑对象头 2025-05-22
  • (评论) 2025-05-11
  • (评论) 2025-04-15
  • (评论) 2025-03-28
  • (评论) 2025-05-21

  • 原文
    Hacker News new | past | comments | ask | show | jobs | submit login
    JEP 519: Compact Object Headers (openjdk.org)
    70 points by Skinney 19 hours ago | hide | past | favorite | 10 comments










    The previous JEP 450 [1] has a lot more implementation details for those who are interested.

    > They have been tested at Oracle by running the full JDK test suite. They have also been tested at Amazon by hundreds of services in production, most of them using backports of the feature to JDK 21 and JDK 17.

    One of the underappreciated perks of working on platform teams in large (and very large in the case of Amazon) companies is that you've got a playground to see and quantify the impact of your performance work that few others have.

    [1]: https://openjdk.org/jeps/450



    I find it a bit bizarre that this JEP doesn't enable Compact Object Headers by default. Most users will not know to specifically enable it, so if they're that confident in its stability and performance, why not enable it for everyone?

    The JVM used to have a reputation for requiring byzantine flags to properly optimise its performance (mostly GC configuration). We've mostly left that behind these days, but it feels like JEP 519 takes a step backwards here.



    The JVM world is slow and extremely careful. If there's a chance something that once works breaks, it'll take many years before the change is applied by default.

    Many JVM users can make huge performance gains by switching the GC to a better once and by toggling all kinds of options.



    That would be the LTS track. A change has no effect on the LTS version which is supported for a long time


    These things tend to be done gradually out of an abundance of caution. Assuming the experience remains positive, it will be made the default in some future release.


    This particular JEP is just: "Change compact object headers from an experimental feature to a product feature."

    Very good performance results though. Particularly like the json parsing benchmark showing a 10% performance improvement.



    I wonder if this also improves the efficiency of native image graal built executables?


    'this', making the future non-experimental won't do anything. It was already available. With this change it still won't be the default setting.

    So, you still need to run some perf. testing on your own to decide.



    This is a change to the OpenJDK JVM (HotSpot) only. I'm not sure, but I think that Graal Native Image (based on the Substrate VM) may already have small headers.


    I’m asking if this JEP will also improve the performance of native image graal built executables, or only when an app is ran using the jdk?






    Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact



    Search:
    联系我们 contact @ memedata.com