• HearMeOut (unregistered)

    Putting a button in the UI that does something but not actually anything hurtful or counter-productive is actually a nice psychological trick - you know, like progress bars. They all lie to users but they still help somehow (https://austinhenley.com/blog/fixprogressbars.html).

  • (nodebb) in reply to HearMeOut

    Pretty much this, specifically because it gives the user an illusion of control, that feeling that "Hey, it seems to be messing up somehow, I'll push the 'stop messing up' button"... (Even though the button does nothing at all, or nothing that makes any difference, e.g. calling System.gc();.)

    But the thing about progress bars is that they are very often set up to track the wrong parameter. Time-remaining for downloads or uploads is notoriously flaky, because it's measuring/calculating something that is subject to variations that cannot be controlled by the downloader. Instead, we should track amount-transferred as a fraction of total-amount-to-transfer, both of which should be known. (A downloader that doesn't track the amount it has already downloaded correctly is a severe WTF, and it has been possible to know how big the object being downloaded is before it finishes for more than 25 years, so no excuses.)

  • (nodebb)

    I am more surprised that initiating garbage collection in Java is not guaranteed. Sounds to me more like a bug than a feature lol

  • xorium (unregistered) in reply to MaxiTB

    Calling System.gc() is not guaranteed to run the garbage collector. But it is implemented as starting unless a garbage collection is underway at that moment.

    I found that the default mechanism fails sometimes when loading very large images; the garbage collector seems to start too late then, and an OOM error ensues.

  • Chris (unregistered) in reply to Steve_The_Cynic

    [citation needed]. I don’t think I’ve ever seen a download or file copy progress bar which is based on time. Complaints about estimated remaining time are common, but those estimates are separate from the progress bar.

  • Loren Pechtel (unregistered)

    Sounds to me like some diagnosis skills are needed here. Don't assume they were nuts.

    Now, I have no meaningful Java experience but I expect the same things I've seen from the C# .NET environment apply.

    1. Squirrelly behavior cleared up by the garbage collector? There's a resource used somewhere, the destructor would free it but it's not actually being called. Run the garbage collector, the finalizers get run, the resource gets freed.

    2. Memory. Working theory (I haven't attempted to prove/disprove): the .NET allocator thinks it's god. It's willing to use vast amounts of "available" memory rather than run the collector--but when it's not the only player it doesn't share nicely. It will let the working set grow to the point of causing stuff to swap. I've found that occasionally checking memory used vs what I would expect and triggering the collector when they're too far out of balance makes a better neighbor.

  • Pr0methean (unregistered)

    IntelliJ IDEA runs System.gc() whenever you click the heap-space meter in the bottom-right corner. Having the GC run while you're off pouring coffee vs desperately waiting for your Find Usages results can make a big difference.

  • (nodebb) in reply to Loren Pechtel

    "2. Memory." I have run into this with .NET Framework. The GC runs on different 'aggression' levels depending on ServerOS/DesktopOS/Service/GUI. Some of my applications do large numbers of image/bitmap manipulations in a row, and GC does not always keep up (Objects are available for GC), resulting in heavy memory use and trashing pagefile. Solution has been, at intervals to check, if process memory use > PI * Thumb, and then call GC.

  • (nodebb) in reply to Loren Pechtel

    It will let the working set grow to the point of causing stuff to swap.

    The problem with this statement is that what's growing isn't the working set, because it's just allocated-but-no-longer-wanted (by the programmer) memory that hasn't been recovered by the GC yet. If the "true" working set (memory blocks you're using rather than them plus the stuff that's waiting for the GC) is growing like that, you have a different problem.

Leave a comment on “Best of 2025: Too Many Red Flags”

Log In or post as a guest

Replying to comment #689273:

« Return to Article