Allocating a large block can be problematic.  There may be no hole big
enough to fit.  You have to do a garbage collection or compaction to
make room.

Obviously there is more overhead allocating 10 small objects than one
big one given that room can be found without gc.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Jimmy:

   Multiple allocations will be slower as you go through the allocation
code that many more times, but the ratio may not be what you expect. There
is a linear component to allocations within Java in that it requires that
all uninitialized fields of an object be set to zero for primitives and Null
for references. This initialization means that a large allocation's timing
may be dominated by the clearing of memory. The performance ratio will be
set by the VM's implementation of memory allocation. If the VM sub-allocates
out of a large memory chunk, the timing may be faster, but if it allocates
from the OS's allocator, then there will be additional overhead from
acquiring a global lock for memory access.

   Garbage collection is another area where the type of collector plays a
big role. All collectors will spend a lot of time either incrementally or
bulk scanning of the thread stacks and heaps to determine object liveness
(hence collectability). More objects - more time.

   Java however does not let the user directly allocate memory any ways
except as an object or some variant of an array. The most common ways of
avoiding many allocations in systems that care about it are using object
pools to manage the memory yourself (assuming you know upper limits) and
implementing multidimensional arrays as larger linear arrays with
row/column/plane calculations performed by the software instead of the
internal walking of arrays of arrays of arrays of ... arrays of
primitives/objects.

   The better answer to this would be for you to explain your problem and
why memory allocation is troublesome.

Mark...