Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • GC's haven't freed us from manual memory management, you just do all that manual work with environment variables, or making sure to "pick the right collector for the job", or debugging performance or heap size issues, or chasing down weak references or confused finalizers.
    by stmw
  • > you just do all that manual work with environment variables

    You really don't anymore. For the past several years, Java's GCs mostly pick the right settings automatically, except for heap size, which will be taken care of soon (https://openjdk.org/jeps/8377305). The reason heap size isn't automatic is that with moving collectors it determines the CPU/RAM tradeoff, and doing that in a more natural way isn't trivial, but we have the algorithm now and will merge it soon.

    > or making sure to "pick the right collector for the job"

    There are really only four options, most of which are easy to choose among: Parallel for batch jobs where only throughput matters, ZGC for interactive applications where latency matters a lot, and then consider either G1 or Serial if there's a problem with those choices.

    As someone who's worked for a long, long time solving manual memory management issues, the amount of effort required isn't just in a different ballpark, but in a different city. Sure, spending a few hours a year to reconsider your settings isn't nothing, but it isn't even remotely in the same category of pain with manual memory management (or even automatic memory management, but with malloc/free underneath).

    by pron
  • Huge thanks to the OpenJDK Team! I still can't believe we are finding incredible improvements. The JVM is an engineering marvel
    by exabrial
  • > selecting something else depending on arcane environmental conditions was more of a burden than an advantage

    What is being referred to here? Does "else" refer to ZGC, Shenandoah?

    What does arcane env conditions mean?

    by smallnix
  • It's in the JEP (https://openjdk.org/jeps/523):

    > We made G1 the default collector for server environments in JDK 9 (JEP 248). At that time, testing showed that Serial had significant advantages in throughput and footprint in constrained environments with a single CPU or less than 1792 MB of physical memory. We therefore adjusted the JVM's GC selection algorithm to choose Serial in such environments.

    by aatos
  • If any JDK wizard is present:

    In my opinion, the thing the JRE is REALLY missing is a single process level memory limit setting.

    Nowadays you still have to consider the off heap memory when limiting a JRE processes max memory.

    To clarify: -XX:MaxRAMPercentage should not exist. Instead the process should be told: „You can use x mb/gb of memory. Use of that what you need for offheap and use the rest for heap.“

    That setting is embarassing. Figuring out its value is a mixture of voodoo, vibe-driven guessing and playing the game of „how much wasted memory do you want to risk to prevent a crash?“.

    Give us -XX:MaxProcessMemory=4g please. Why doesn‘t this exist?

    by Traubenfuchs
  • Are people still dealing with GC issues?

    I find that it basically just more or less works out of the box on modern JVMs.

    by kasperni
  • Perhaps. That's why actual JVM GC developers are talking about it.
    by geodel
  • > Are people still dealing with GC issues?

    Have you tried real-time audio processing for digital radio communications on a JVM that requires sub-millisecond latency on older, temperature-hardened CPUs?

    by thangalin
  • There are edge cases where GC issues can crop up, in particular specific "serverless" models (eg AWS lambdas) where the JVM can get "paused" between executions and GC doesn't cleanly run, causing memory to trend upwards until the next cold-start happens (especially if you're running it within a docker container yourself). Limited CPU situations that can exist in these kinds of runtime environments also limit GC in several ways, too.
    by hylaride
  • It's selection bias. There's a huge number of GC language users, but those who experience problems tend to be the ones who comment.

    You're right; the vast majority of people use GC just fine and go about their day. We should update little to none when we see evidence of GC hardship.

    by kelseyfrog