Thu Feb 18 14:43:00 GMT 1999
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
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.
From: Jon Olson <email@example.com>
To: Jerry Kramskoy <Jerry.Kramskoy>; Per Bothner <firstname.lastname@example.org>
Cc: email@example.com <firstname.lastname@example.org>
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
>>increase in RAM occupancy ... which may well be of concern to
>>embedded system manufacturers. But it certainly makes GC compaction
>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
>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
> 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
> Thus, if the collector only supports 64 and 96 byte allocations, and
> allocate 65 bytes, the remaining 31 bytes are wasted.
> 3) Less so but still significant, conservative non-copying collectors
> alot of general bookkeeping overhead to keep track of their colors,
> 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
>Jon Olson, Modular Mining Systems
> 3289 E. Hemisphere Loop
> Tucson, AZ 85706
More information about the Java