Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Smart resource system  (Read 1892 times)
0 Members and 1 Guest are viewing this topic.
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Posted 2004-05-04 17:01:31 »

I'm curious if anyone has had any success implementing a smart resource system in a Java game/engine.

What I'm referring to is a system in which resources are removed from memory (unloaded) once a specific threshold has been surpassed. A resource manager tracks each resource (via a LRU scheme or some such). When a new resource load is requested, the manager checks the threshold and unloads any previously loaded but currently uneeded resources if neccesary. When an active unloaded resource is later requested by the game, the manager loads it after first making room by unloading something else.

Considering that the only way to unload a resource in Java would be to null it and ensure that no references to it exist, I'm concerned about the potential for triggering the gc too often. Additionally, since the nulled reference will still be resident in memory, I'm also concerned about cases where a gc is not triggered - causing a resource to actually be in memory twice (the active, referenced one and the nulled one waiting to be gced).

This sort of system is very useful for games with large terrain sets, oodles of models, and numerous sound effects/music.  By dividing the world into zones, only the resources belonging to the current and adjacent zones need be initialized at a given time. And of those, only a subset need actually be resident in memory.

Anyone have any experience with a Java implementation?
Offline Jacko

Junior Member





« Reply #1 - Posted 2004-05-04 23:01:56 »

Isnt this something you would worry about with native bytebuffers? On the Java side the GC will look after all this for you whatever you try to do. If you allocate yourself a big direct bytebuffer, you could then look after it yourself, with the GC not being involved.
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #2 - Posted 2004-05-05 04:26:01 »

The fact that the GC looks after everything is what concerns me Wink. Swapping lots of stuff in and out of memory is sure to cause more gc-induced pauses than I would like. Nothing is ever proven until implemented and tested, of course. Which is why I'm hoping someone around here has already been-there-done-that.

As for Bytebuffers, I don't see how that would be different. There is still no way to implicitly free the memory. The direct memory would still be allocated until the ByteBuffer is itself gc'ed, correct?

Unless (after rereading) you are suggesting that I use a ByteBuffer to hold all of the resource data. That's something I had not considered. But my first thoughts are that it would be way more trouble than it's worth.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #3 - Posted 2004-05-05 05:50:02 »

>I'm concerned about the potential for triggering the gc too often

Actually, you want the GC to run often. If it has enough time to run often, there won't be much to do - therefore no "halt of the world" effect.

Enabling vsync or using framecapping helps alot (usually you won't have any gc pauses then). Also there are alot of neat switches for tweaking.

弾幕 ☆ @mahonnaiseblog
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2004-05-05 21:32:33 »

Quote
Considering that the only way to unload a resource in Java would be to null it and ensure that no references to it exist, I'm concerned about the potential for triggering the gc too often. Additionally, since the nulled reference will still be resident in memory, I'm also concerned about cases where a gc is not triggered - causing a resource to actually be in memory twice (the active, referenced one and the nulled one waiting to be gced).


Read up on Soft-References (there are several kinds, 'Weak', 'Phantom' etc..)
GC won't do much if it doesn't NEED to .. if you aren't allocating new resources, just having old stuff still in memory shouldn't be a problem.
Soft References will solve your other problem of 'resurrecting' garbage.

http://java.sun.com/developer/technicalArticles/ALT/RefObj/

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/SoftReference.html

Pages: [1]
  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.

xsi3rr4x (31 views)
2014-04-15 18:08:23

BurntPizza (28 views)
2014-04-15 03:46:01

UprightPath (43 views)
2014-04-14 17:39:50

UprightPath (26 views)
2014-04-14 17:35:47

Porlus (42 views)
2014-04-14 15:48:38

tom_mai78101 (64 views)
2014-04-10 04:04:31

BurntPizza (124 views)
2014-04-08 23:06:04

tom_mai78101 (224 views)
2014-04-05 13:34:39

trollwarrior1 (190 views)
2014-04-04 12:06:45

CJLetsGame (198 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!