- Feature Articles
-
CodeSOD
- Most Recent Articles
- A Sudden Tern
- Going Through Time
- A Pirate's Confession
- The Review
- No Yes
- The Utils
- A Case of Old Code
- Linguistic Perls
-
Error'd
- Most Recent Articles
- Chicken Feed
- Twofers
- Two-faced
- Boxing Day Math
- Michael's Holiday Snaps
- Anonymice
- A Horse With No Name
- On the Dark Side
-
Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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).
Admin
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.)
Admin
I am more surprised that initiating garbage collection in Java is not guaranteed. Sounds to me more like a bug than a feature lol
Admin
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.
Admin
[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.
Admin
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.
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.
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.
Admin
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.
Admin
"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.
Admin
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.