🔒 Locked
java memory management
Advertisement
Original Post
Basically if I create an object using new I allocate the memory. Now in C++ if i''d want to recreate it with new i''d first free the memory with ''delete''. What happens in java?
Will the memory automatically be freed when I call new again.
-CProgrammer
Java utilizes garbage collection, so whenever your program loses its reference to something you allocated, the memory is automatically reclaimed periodically. You basically don't ever have to worry ever about releasing memory allocated with 'new'.
[edited by - Zipster on May 2, 2004 3:00:27 AM]
[edited by - Zipster on May 2, 2004 3:00:27 AM]
Ok thats practical. Thanks
-CProgrammer
-CProgrammer
System.gc may not actually do anything and most Sun white papers say never call it. If you don''t want to garbage collector to run at a critical time don''t allocate any memory in you game loop.
"... we should have such an empire for liberty as she has never surveyed since the creation ..."
Thomas Jefferson
"... we should have such an empire for liberty as she has never surveyed since the creation ..."
Thomas Jefferson
quote:
If you don''t want to garbage collector to run at a critical time don''t allocate any memory in you game loop.
This is really easy once you get used to the concept of ''object reuse''. Then you''ll be reading c++ code and thinking, ''man these guys are sloppy with memory allocation...''
quote:
Original post by nonnus29quote:
If you don''t want to garbage collector to run at a critical time don''t allocate any memory in you game loop.
This is really easy once you get used to the concept of ''object reuse''. Then you''ll be reading c++ code and thinking, ''man these guys are sloppy with memory allocation...''
Plus, java objects are all allocated on the heap, instead of the stack...so there''s some overhead there also. so the rule is little/no new''s in inner loops
quote:
Original post by Pipo DeClown
I heard you just have to point the ''fake pointer'' to null. Then the GC knows what to collect.
If the GC can tell the reference points to null, it can tell when there are no more references in the current scope. Throwing obj = null;''s does nothing to help readability, either and can potentially be misleading -- its not like the finalizer is guaranteed to be run when you set the reference equal to null.
Don''t treat the GC like you would treat the freestore in C/C++. It''s going to collect when it needs to and you can''t really do much about it.
quote:
Original post by GKW
System.gc may not actually do anything and most Sun white papers say never call it. If you don''t want to garbage collector to run at a critical time don''t allocate any memory in you game loop.
According to the spec, you really can''t deterministically control when the garbage collector runs. That includes both forcibly trying to cause it to run (as in calling System.gc()), as well as forcibly trying to prevent it from running. Simply not allocating any memory in your game loop won''t have any effect on how frequently or when the GC runs. The less memory you allocate, however, the cheaper the GC runs are likely to be.
The reality is that you cannot achieve fine-grained control over the GC (some would argue that this is the point of using systems like Java with managed memory). It is also true that you cannot avoid allocating memory and still do much of interest in your program.
What you can do is tune the garbage collector to behave in a more friendly way with your program. For highly interactive environments (like games), it can be very jarring for the user to have a single frame every once in a while take 2-3 seconds, which can happen when the GC kicks in in the background.
Luckily, Sun''s VM provides an option that can alleviate this as of JDK 1.3, called "incremental GC." Incremental GC divides up the heap into smaller chunks called "trains", and runs quicker but more frequent sweeps to clear these heaps out. This has the effect of ammortizing the cost of the GC over several runs. It may add on average a few hundredths of a second to each frame, but it''s not likely to spike and take 2-3 seconds for any given chunk. More detailed information about the GC algorithms in Sun''s 1.4.1+ VM are here [http://www.javaworld.com/javaworld/jw-03-2003/jw-0307-j2segc.html].
Hope this helps.
Exactly, if you don''t allocate anyting a GC run will only take a few thousandths of a second. I believe Sun is removing the incremental collector from jre 1.5 and up so that won''t be an option come this fall.
"... we should have such an empire for liberty as she has never surveyed since the creation ..."
Thomas Jefferson
"... we should have such an empire for liberty as she has never surveyed since the creation ..."
Thomas Jefferson
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement