The problem is, the objects are small, but plenty in number. u can
think them as 2D points ... and I have a fixed size array for them...
Now I access them sequentially, but may not create them sequentally.
Thus if I dont have all the points in nearby place in memory it not
only causes one extra indirection, but also cache overflow. The cost
comes high for computational geomery....
I event dont want the objects to be garbage collected. When I create a
new point, I want to put it it the array at the appropriate place (The
array behaves like a circular buffer here). Thus, no memory management
is at all needed for these large number of objects in practical sense.
(Want to do something like C++ placement new, which is used inside STl
vector class). Thus garbage collector will also get a relief rather
than managing large no of objects to e garbage collected....
Well, when a new Point comes, I really create a new point to put it
into a circular buffer,
rether than reintializing the field of the old point, which was already
there to a new value.
This is done, to keep in mind, I do computation on them in seperate
thread. Once I create a point, it is immutable, fields can't be
changed. Thus thread synchronization problems are not there (which is
another costly thing to do).
Now the points come, the circular buffer stores them, discards the
old, and process in different thread.
Thus, it is better to have them in neaarby memory place, and not t get
garbage collected.
 To me, it looks very much like C++ by value array, or C# struct.
 The general method do work, but time goes high, ( I think java do
outperform C++ even when it comes for looped processing... or hot
spots, and it has reason to do so). But this  is a particular case
where I feel, stack allocation is better, and garbage collector should
not perform...
I have heard that mustang ( Java1.6) performs escape analysis to
allocate small objects in stack rether than heap, to speed up this kind
of feature... Do anyone know how it performs?

abir