[OpenJDK Rasterizer] RFR: Marlin renderer #2

[Jim Graham]

Hi Laurent,

Here's a suggestion on how I would set up the array caching code, mainly 
with regard to making it easier to make sure we are managing then 
consistently, but also to allow for more flexible tuning later.

First, make all interactions go through the cache object itself - get, 
grow, put.  This gets rid of a number of static methods with a bunch of 
similar names and groups the management methods in a class hierarchy.

Second, have each consumer of arrays use its own cache object.  Some of 
them may be the same object reference between different "users", and 
some of them may be different objects but share their underlying arrays 
with each other, but a given piece of code could be traced to always 
get/grow/put its arrays into the same cache object.  That way it's 
easier to see that you aren't mixing/matching clean/dirty arrays.

DirtyFooCache
     foo[] get(size)
     foo[] grow(foo[], newsize)  // or widen?
     void put(foo[])

CleanFooCache
     foo[] get(size)
     foo[] grow(foo[], newsize, <used parts>)
     void put(foo[], <used parts>)

Then code that manages an array named bar would be managed as:
(It may be the same instance as another FooCache
  or it may share its arrays with another FooCache
  but the "barCache" reference is only ever used for the bar array...)
     [Clean|Dirty]FooCache barCache = make/get/share a Cache instance;
     foo[] bar;
     ...
     bar = barCache.get(initSize);
     ...
     bar = barCache.grow/widen(bar, newSize[, usage if clean]);
     ...
     barCache.put(bar[, usage if clean]);
     bar = null;

It's easier to verify that bar is being managed consistently if it 
always goes back to its own bar object.  You can then decide if too 
different uses of foo[] arrays should share the same arrays or not based 
on profiling.  You can also potentially have different growth algorithms 
for 2 different arrays of the same type, but possibly even sharing the 
same underlying arrays.  Any degree of customization is possible 
underneath the covers behind a FooCache basic interface.

I'd also either make the growth heuristics an argument to 
creating/fetching a FooCache instance or make it subject to a helper 
"CacheSizeManager" or "CacheSizeStrategy" object in such a way that 
different uses of IntCache might be able to have different growth 
strategies - and to possibly even manage different sizing strategies on 
top of the same set of underlying arrays (i.e. one has buckets that grow 
by <<2 and another by <<1 and for the even buckets, they share arrays, 
for instance).

The main thing for the near term, is that it would be nice to have each 
array use its own cache object so that we can easily verify that it is 
being consistent with its handling of arrays...

			...jim