Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  [Forcefully clean allocated memory]  (Read 4978 times)
0 Members and 1 Guest are viewing this topic.
Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #30 - Posted 2013-01-25 11:59:02 »

Sorry if this has been mentioned, I kind of skipped over the drama.

I had this weird idea.

Let's say that, for whatever reasontm (aka let's not argue when this would be useful), your program needs to strictly manage memory.

Would it be interesting/worthwhile/not insane to design the program around an static (as in invariant, not as the Java meaning of static) memory allocation?

Meaning, you decide your program should only store up to 20Mb in memory, so at the start of the program you allocate said 20Mb, and only use your pre-allocated memory (specifics of how it would be allocated aside).

Similar to a Thread Pool. Could call it a Memory Pool, or Memory Buffer... Or You're Doing It Wrong. Tongue


Thinking about it, this could be useful in situations where data loading is unbounded, for example some sort of recursive loading loop, and you want to make sure it doesn't grow out of control.

Offline nsigma
« Reply #31 - Posted 2013-01-25 12:39:51 »

What a fun thread to start my day with.  Reminds me of an old T-shirt slogan "Your village called, their idiot is missing"  Grin

If I see a program in front of me that's using 25MB of memory when it clearly only should be using 9MB (Just a example), if I can forcefully call 'Garbage Collection' when I choose too and get rid of unused / nulled objects lying around accumulating unnecessary space, of course I will. (Knocking it back down to 9MB)

I'm intrigued by what the OP thinks that code is doing, too.  Not seen if anyone else has mentioned this, but the other flaw with this would be that while this might release memory within the JVM, it's extremely unlikely that the JVM will release that back to the OS - so in terms of keeping the memory usage of your program down it's even more pointless.

Meaning, you decide your program should only store up to 20Mb in memory, so at the start of the program you allocate said 20Mb, and only use your pre-allocated memory (specifics of how it would be allocated aside).

Yes, let's recreate the JVM using the JVM!  Tongue

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Roquen
« Reply #32 - Posted 2013-01-25 13:18:57 »

Quote
Yes, let's recreate the JVM using the JVM!
Ah, but that is crazy like a fox.  IBM's research JVM (JikesRVM) is written in java and Oracle's (potential) HotSpot replacement VM Maxine is 100% java.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Grunnt

JGO Wizard


Medals: 64
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #33 - Posted 2013-01-25 13:23:28 »

THIRD TIME:
Everywhere I've looked for methods on forcefully invoking garbage collection yield back the same result.......
"No, you cannot forcefully call GC, you can only suggest it."

Let me quote the Oracle Java documentation for System.gc():
Quote
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
(from http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/System.html#gc())

According to spec: you "suggest" that the garbage collector "expend effort" towards garbage collection. Nowhere does it say that "suggest" implies "force". Repeatedly suggesting something does not make it "forced". If in your anecdotal case the VM happens to follow up on your suggestion (which it may have done anyways), that really does not say anything.

And also from Runtime.freeMemory():
Quote
Returns the amount of free memory in the Java Virtual Machine. Calling the gc method may result in increasing the value returned by freeMemory.
(from http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Runtime.html#freeMemory())

In other words, you're releasing memory not to the system (i.e. for other applications), but to the JVM your app is running in. Memory that the GC would have made available to the JVM's applications anytime they actually need it anyway. It's wonderful what you can learn from just reading the manual.

In short: your approach does not help in any way, and just interferes with the highly optimized garbage collection approach taken by modern JVM's. But I guess all of this has been said before on this thread Grin

Offline sproingie

JGO Kernel


Medals: 201



« Reply #34 - Posted 2013-01-25 17:01:20 »

System.gc does result in a gc fairly soon, unless there's extraordinary circumstances preventing it.  It's still run asynchronously, with no completion notification available, so the method at the moment you call it is still a no-op, and the OP's insistence that it guarantees anything falls flat in the face of any other thread doing allocation.  And there's the whole matter that it triggers an expensive full gc.  Anyway, I think any newbies who run into this thread have already been duly warned.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #35 - Posted 2013-01-25 19:46:00 »

Ok guys I think he and the rest of the world gets it. We're just repeating each other now and most likely doing permanent psychological damage  Grin

Offline GabrielBailey74
« Reply #36 - Posted 2013-01-25 20:30:51 »

Ok guys I think he and the rest of the world gets it. We're just repeating each other now and most likely doing permanent psychological damage  Grin

Lol. Grin

I'll think twice before posting something next time lol.

I'm getting ready to post a snippet on 'Manipulating Java2D into Java3D', sound good?
Or should the criticism start in this thread lool

Offline theagentd
« Reply #37 - Posted 2013-01-25 21:59:40 »

I'll think twice before posting something next time lol.

(snip)

Or should the criticism start in this thread lool

Misinformation is dangerous to newbies, so people on this forum will point out mistakes. In contrast to IRL, people actually feel okay being brutally honest with you thanks to the anonymity of the internet, so you have to be prepared to get criticism on what you post, especially if it's something technical and does have a "right" or "wrong" (in contrast to more artistic work). Your post makes it sound like criticism is a bad thing.

Myomyomyo.
Offline sproingie

JGO Kernel


Medals: 201



« Reply #38 - Posted 2013-01-25 23:18:58 »

Punctuating every sentence with "lol" doesn't help.  I can't be the only one with that peeve.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #39 - Posted 2013-01-26 03:25:50 »

tehe!

I'll think thrice before thinking next time tehe!





tehe!

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline GabrielBailey74
« Reply #40 - Posted 2013-01-26 04:23:34 »

tehe!

I'll think thrice before thinking next time tehe!





tehe!

"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.

Offline ra4king

JGO Kernel


Medals: 336
Projects: 2
Exp: 5 years


I'm the King!


« Reply #41 - Posted 2013-01-26 04:28:21 »

No. Cranky

Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #42 - Posted 2013-01-26 04:32:04 »

This thread is a fun one  Cool

Offline sproingie

JGO Kernel


Medals: 201



« Reply #43 - Posted 2013-01-26 05:15:48 »

Yeah it is, lol!   Kiss
Offline Best Username Ever

Junior Member





« Reply #44 - Posted 2013-01-26 05:38:29 »

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
rt.freeSpace(); rt.gc(); rt.freeSpace()
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.
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #45 - Posted 2013-01-26 09:53:29 »

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. 

Time flies like a bird. Fruit flies like a banana.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #46 - Posted 2013-01-26 10:11:16 »

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 Smiley

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 Smiley

Offline Roquen
« Reply #47 - Posted 2013-01-26 13:09:28 »

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. 
Offline sproingie

JGO Kernel


Medals: 201



« Reply #48 - Posted 2013-01-26 17:05:09 »

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.
Offline deepthought
« Reply #49 - Posted 2013-01-27 04:47:34 »

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.

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #50 - Posted 2013-01-28 14:00:06 »

Meaning, you decide your program should only store up to 20Mb in memory, so at the start of the program you allocate said 20Mb, and only use your pre-allocated memory (specifics of how it would be allocated aside).

Yes, let's recreate the JVM using the JVM!  Tongue

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



Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #51 - Posted 2013-01-28 15:05:35 »

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.
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 Smiley

Offline Roquen
« Reply #52 - Posted 2013-01-28 22:06:51 »

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.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #53 - Posted 2013-01-28 23:35:20 »

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 Smiley

Offline Roquen
« Reply #54 - Posted 2013-01-28 23:53:11 »

That's rather disappointing.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2013-01-28 23:54:18 »

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 Smiley

Offline Best Username Ever

Junior Member





« Reply #56 - Posted 2013-01-29 00:21:43 »

How long ago was that? Does it still crash?
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #57 - Posted 2013-01-29 01:03:58 »

Only last year, I've not bothered to try it since ("if it ain't broke" etc)

Cas Smiley

Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (26 views)
2014-07-24 01:59:36

Riven (25 views)
2014-07-23 21:16:32

Riven (19 views)
2014-07-23 21:07:15

Riven (22 views)
2014-07-23 20:56:16

ctomni231 (51 views)
2014-07-18 06:55:21

Zero Volt (46 views)
2014-07-17 23:47:54

danieldean (37 views)
2014-07-17 23:41:23

MustardPeter (40 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!