[Forcefully clean allocated memory]

Shared Code
#41

“tehe”
A word used to replace lol or haha. Much more cute way of laughing! Or can be used to look innocent. Only cute when girls say it. Don’t overuse it.
Bob: Where’d my tighty whities go?
(From down the hall, in another room)
Maria: tehe!

lol, when I say ‘lol’ I’m most likely loling IRL, I’m younger than most on here id’ presume (18) so I use ‘lol’ commonly and internet slang.
Not a trademark of minors of anything lol.
^
See, that was appropriate I lol’d IRL –^
Meh lol, yeah you get it.
http://www.420magazine.com/forums/images/smilies/smokin2.gif

#42

No. :cranky:

#43

This thread is a fun one 8)

#44

Yeah it is, lol! :-*

#45

:cranky: Despite “evidence” that it works, it is not actually doing anything. Java is not C++. You do not use destructors. You do not treat objects as handles that automatically free the resource it links to. Unreachable objects do not prevent new objects from being allocated. Those objects do not hurt you. After an object is dead (and before a garbage collection cycle starts), the “age” of that object is irrelevant. It does not slow down the garbage collection process, only reachable objects can do that. The fact that it is dead means it’s space is reclaimable, only live objects prevent that. It does not prevent new objects from being allocated because it provides space to allocate from.

Free space includes reclaimable memory. The problem with determining free space is that you do not know if a given block of memory is live or dead until it gets garbage collected. If it is dead, that is technically free space. freeSpace() returns an approximate value. That is probably for the reason I described. Your free space is at least as much as your unallocated reserved heap space. The exact space could be as much as the entire heap if every object on the heap is dead and the lower bound can be as low as zero. A function could tell you a lower bound on the amount of free space you have, but you cannot know the exact value unless you stop the entire program, visit every live object on the heap, and deduct that total size from the total heap space.

Calling gc() and then checking freeSpace() does not create more free space. It stops your entire program at an inconvenient time, stops all program threads until the full garbage collection completes, and then starts the program again.

At best (assuming you are using a single thread; gc() is not ignored; gc() triggers a new, immediate, full, stop the world garbage collection cycle; and freeSpace() reflects the exact space that is only possible to know after that process) you only know exactly how much space is free. The amount of free space available for a single threaded program does not change if you call [icode]rt.freeSpace(); rt.gc(); rt.freeSpace()[/icode] in that order. The amount of space available for allocating objects is the same because Java can find new space to reclaim while doing an object allocation. (Garbage collection can be done inline with object creation. Object creation is never prevented if the VM implementation can eventually find space to use even if it has to move things around.)

So if you want to know exactly how much free space you have and are willing to wait to know, then calling gc() then freeSpace() might tell you that. Otherwise you are only forcing an earlier garbage collection cycle (assuming gc() actually does something). There might be some positive side effects if you don’t care about responsiveness, but there are also negative side effects.

And it is true that you can’t force Java to do a garbage collection. Suggesting it do so in a loop would be like suggesting Oracle give you the trademark rights to Java every day until it did so. The VM can ignore your suggestion.

#46

If it’s any consolation, I tried much the same thing when I started programming java. I thought that if I regularly cleared out the garbage, then there would be a small overhead per frame, but no big stuttering freezes. There are several different garbage collection strategies available (IIRC) and I tried all of them. Then I found that it didn’t work very well and the best solution really is not to create any garbage in the first place. That way my garbage collection takes 0% of my frame time. Now if I see a frame stutter, I immediately search the inner game loops to see where I accidentally allocated something on the heap.

Incidentally, no body likes to admit an error, but carrying on with a mistake seldom makes sense. Some people get away with it professionally by moving on before they are ‘found out’, leaving a trail of wreckage behind them. If they are smooth talkers they can get promoted quite quickly, but often come unstuck if they fail to move on before the shit hits the fan. Otherwise, for us mere mortals, the best thing is to fix the error quietly and carry on. Incidentally I remember one guy who did really well out of fixing his error, as his boss was so relieved when the fix was in, he quite forgot why the problem had arisen in the first place.

#47

I’m glad I figured out garbage collection as soon as I started doing Java or I’d be in a right mess by now :slight_smile:

Amazes me that “real” programmers still don’t seem to understand it - for example Apple’s (presumably) senior engineers discourage the use of GC on iOS because they think it will “consume too much power” and “slow things down”. Unbelievable in the face of all the evidence. And practically every games programmer I meet tells me that they want “precise control of when an object is deleted” because they want it to be “as fast as possible” (needless to say they are C++ programmers, poor things). Maybe part of the problem is that widely available GC libraries for C++ aren’t all that great compared to what we’ve got.

Cas :slight_smile:

#48

I’d say that I can always beat current generations of GC at their game. BUT: so what? It’s a narrow usage skill set that takes lots of practice and the rules are mutating all the time due to changes in memory architectures. The gains, for most people, simply aren’t worth considering…so developing the feel for it is a useless party trick. Of course more importantly it’s moot in Java.

This topic falls under a wider category of “why are you fighting your chosen language”? When you start down that route you should be really confident that there are no other practical paths available.

#49

Most game programmers don’t care so much about precise control of individual objects as they want the gc to be deterministic and able to be paused in critical sections, and stock JVMs don’t give you either. Objective-C, with its slow-ass reference counting, at least pays a reasonably deterministic cost.

It’s C programmers who cling to their malloc/free who are hopeless. They act as if their preferred memory management primitives have zero cost themselves.

#50

Only place I could think of to call System.gc() really would be between levels if you got rid of a lot of objects so you have a clean slate. I agree with everyone else that constantly nagging java to do garbage collection won’t get you anywhere.

#51

So, in other words, the same effect can be achieved by tinkering with the memory allocation of the JVM, is that right?

#52

And indeed, if you now use -Xinggc and -XX:MaxGCPauseMillis=3 (or similar values) you’re going to get as near as deterministic as you realistically need to get. You’re as likely now to lose 5ms to a GPU hiccup as a Java one, so… meh.

Cas :slight_smile:

#53

If you’re willing to limit yourself to 7u4+, then the G1 collector might be worth a go. Otherwise, like I said earlier…there are a tons of tweakables here. A good choice, sadly, is going to application dependent.

#54

I had pretty mixed results with G1 - was expecting it to be awesome but in the end it seemed to use an awful lot of CPU and didn’t really smooth anything out. Also, it tends to crash the VM. More work at the labs, Igor!

Cas :slight_smile:

#55

That’s rather disappointing.

#56

I would have kept using it I think, were it not for the crashing. And I suppose that my code really doesn’t generate that much garbage anyway so it’s not really a problem for me.

Cas :slight_smile:

#57

How long ago was that? Does it still crash?

#58

Only last year, I’ve not bothered to try it since (“if it ain’t broke” etc)

Cas :slight_smile: