Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (426)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (466)
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  
  Greedy Garbage Collector  (Read 3375 times)
0 Members and 1 Guest are viewing this topic.
Offline moogie

JGO Knight


Medals: 11
Projects: 6
Exp: 10 years


Java games rock!


« Posted 2010-08-19 09:04:26 »

I had a thought in the shower today (dont ask... i have my best ideas there Tongue )

In this day and age, where harddrive storage space is ridiculously cheap and most people have tonnes of free space, is there any realy need in most applications for any "Real" collection of garbage?

The benefits should be no real long pauses Smiley



A naive impelmentation might be similar to this:

for each "new" instance created allocate required memory. Add to top of Objects-in-RAM-Queue (ORQ).

On request for a particular instance's memory address the following will happen:
1. if the instance is in the ORQ, return the memory address. Add to top of Objects-in-RAM-Queue (ORQ).
2. else if the instance in the Add to Disk Cache Map(DCM). Remove from DCM and add to top of Objects-in-RAM-Queue (ORQ).

a GC thread will periodically monitor the last time stamp (mabe cpu cycle count? ) of the last instance in the ORQ if the instance the time stamp indicates the instance is old then remove the instance from the ORQ and add to the DCM. Repeat this until GC thread time exceeded or last instance is too young.


where the ORQ utlises "normal" RAM and DCM utilises a harddrive or similar.

alternatively perhaps just let the OS deal with the memory requests and manage the paging to disc and so just always allocate memory, never destroy?


Offline Riven
Showcase Moderator

JGO Overlord


Medals: 612
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2010-08-19 09:54:17 »

Remember that every relocation of an Object requires *all* Objects with fields referring to it need to be updated.

That means that if you move an Object, you'd have to iterate over the bazillion objects on disk. That is slow.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Roquen
« Reply #2 - Posted 2010-08-19 12:10:57 »

Waiting on main (uncached) memory is slow...disc access is the waiting for start of the next ice age.  Wink
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline moogie

JGO Knight


Medals: 11
Projects: 6
Exp: 10 years


Java games rock!


« Reply #3 - Posted 2010-08-19 12:16:52 »

Remember that every relocation of an Object requires *all* Objects with fields referring to it need to be updated.

That means that if you move an Object, you'd have to iterate over the bazillion objects on disk. That is slow.

Quote
Waiting on main (uncached) memory is slow...disc access is the waiting for start of the next ice age.

good call Smiley

interesting thought exercise though.

so perhaps it would be best to let the OS do the grunt work (which would be easier Tongue ) and just keep requesting memory and just not release until end of execution.
Offline Riven
Showcase Moderator

JGO Overlord


Medals: 612
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2010-08-19 12:39:26 »

good call Smiley

interesting thought exercise though.

so perhaps it would be best to let the OS do the grunt work (which would be easier Tongue ) and just keep requesting memory and just not release until end of execution.

Sounds like an 'infinite' heap on a 64 bit system.  The functionality you describe is called swapping Wink

The next-big-thing (Garbage First garbage collector) will have 'infinite' 1MB heaps, will make this feasible.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline i30817

Junior Member





« Reply #5 - Posted 2010-08-23 22:42:11 »

I think that a gc helped by a language that has no pointer aliasing by default(ie: with a session types ownership protocol) + a good compiler, would be pretty great. It would  be able to insert memory free on the correct place without programmer intervention (besides the aliasing type when needed) leading to reduced gc pressure. In fact some programs could require no gc at all (guess pure functional), and could be marked as such.

I think it could be awesome, at the cost of a little programmer convenience.
Offline Riven
Showcase Moderator

JGO Overlord


Medals: 612
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #6 - Posted 2010-08-24 00:57:07 »

There is one problem: your harddisk must be fast enough... It's not uncommon to be generating a few hundred MB / sec, if not more. How will you cope with that, if you write everything to disk eventually?

It is a 'good' idea, in a very restricted environment. RealTimeJava has immortal heaps for that reason: no GC, but well, they are finite size and the VM keeps everything in RAM (unless the OS starts swapping).

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline JL235

JGO Coder


Medals: 10



« Reply #7 - Posted 2010-11-30 16:45:24 »

My boss told me a few weeks ago that he learnt object-orientation working on a system kinda like the one described above. All objects were global, used a unique 128-bit reference and were automatically stored to disk (making them permanent). It was apparently ultra simple, very elegant and everything from the language down to the CPU was custom built as one giant OO machine.

Decades years ago it kinda made sense to design big systems from the ground up; but these days it doesn't. There is also the obvious question of: what would you gain from this?

There are also high-end database systems that exist today that constantly write to their tables. Trading systems are a good example. They employ plenty of tricks and high-end hardware to avoid writing unless necessary. If they can work in real-time then there is no reason why this system can't.

Offline erjiang

Innocent Bystander





« Reply #8 - Posted 2010-12-02 02:41:01 »

Remember that every relocation of an Object requires *all* Objects with fields referring to it need to be updated.

That means that if you move an Object, you'd have to iterate over the bazillion objects on disk. That is slow.
If you use two pointers, relocating an object just changes one pointer.
Offline Roquen
« Reply #9 - Posted 2010-12-02 05:40:53 »

Object tables are slow and pollute the cache.
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 (75 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

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

CJLetsGame (220 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!