Current Status

Jerry Kramskoy Jerry.Kramskoy@isltd.insignia.com
Thu Feb 18 14:43:00 GMT 1999


Jon,

I didn't phrase my mail clearly enough   :)

I didn't intend to imply that (non-handled based objects + non-compaction)
is more RAM friendly than (handle based + compaction).

I was assuming (non-handle based objects + compaction +
a GC registration mechanism detailing how to find and edit all references
upon compaction)
.
Then you still get space savings from objects ...

Of course this is a function of the Java app's object usage.
One creating many small objects gets more space savings
percentage wise.  Thanks for the reply.

cheers, Jerry

-----Original Message-----
From: Jon Olson <olson@mmsi.com>
To: Jerry Kramskoy <Jerry.Kramskoy>; Per Bothner <bothner@cygnus.com>
Cc: java-discuss@cygnus.com <java-discuss@cygnus.com>
Date: Thursday, February 18, 1999 3:06 PM
Subject: Re: Current Status


>On Thu, 18 Feb 1999, Jerry Kramskoy wrote:
>>Even more of a consideration with using a handle to access an object is
the
>>increase in RAM occupancy ... which may well be of concern to
>>embedded system manufacturers.  But it certainly makes GC compaction
>>easier.
>>
>>
>Actually, with a compacting collector you'd normally save alot more
>RAM than single reference word would cost.  This is because memory
>in conservative non-copying collectors is allocated in blocks of discrete
units
>each having a given size.  Hence wastage comes in three forms:
>
>  1) Memory in conservative non-copying collectors gets allocated in blocks
>      (often 4Kb or so) and chopped up into as many blocks of a given size
>       that will fit.  Thus, a 4K block contains 256 16-byte blocks.  If
you're
>      only using 128 16-byte blocks, the remainder is wasted and cannot
>      be used for other size allocations.
>  2) Memory blocks only get allocated in certain discrete allocation
quantities.
>      Thus, if the collector only supports 64 and 96 byte allocations, and
you
>      allocate 65 bytes, the remaining 31 bytes are wasted.
>  3) Less so but still significant, conservative non-copying collectors
have
>      alot of general bookkeeping overhead to keep track of their colors,
block
>      lists, etc.
>
>With a compacting collector all the wastage of types 1) and 2) go away.
>Plus, the overhead for 3) can often be smaller since you're managing an
>array of fixed size objects which each point to a single entry in a packed
>heap.
>
>--
>Jon Olson, Modular Mining Systems
>    3289 E. Hemisphere Loop
>    Tucson, AZ 85706
>INTERNET:  olson@mmsi.com
>PHONE:     (520)746-9127
>FAX:       (520)889-5790
>



More information about the Java mailing list