[OpenJDK Rasterizer] RFR: Marlin renderer #2

Jim Graham james.graham at oracle.com
Mon Jun 22 21:20:22 UTC 2015


Hi Laurent,

On 6/22/2015 9:39 AM, Laurent Bourgès wrote:
> I thought you wanted to remove completely initial arrays to simplify the
> code and rely on the cache only:
> that's why I tested the impact of such solution and I set initial arrays
> to [0] to force the cache usage: get/put.

I was saying to eliminate "special handling" of the initial arrays.  In 
other words, all arrays should come from the cache and so there would 
never be any tests for "is this array supposed to be in the cache?".

> So you propose to enlarge the memory footprint consumed by initial arrays.
>
> The bucket #0 size is for now 4096 (16K for int/float arrays) and 32768
> (32K) for dirty bytes.

So, it looks like there is a large jump between initial array sizes and 
the first bucket?

I didn't read through all of your analysis as I didn't understand all of 
your shorthand.  What is the current starting size of all arrays 
compared to the starting size we would have if we forced all growable 
arrays to use their bucket#0 size?

One thought is if the initial memory cost gets too large to have all 
arrays start with bucket#0 sizes, we could also bake the size of the 
initial arrays into the cache object itself, so it would have the 
concept of an initial size and a number of buckets of growable sizes. 
(Or simply a list of sizes and the first size could be much smaller than 
the rest).  At least then the "special size case" would be a part of the 
contract rather than an assumption between the implementation and its uses.

In about a week I might have some free time to prototype an example of 
what I envision for managing growable arrays.  Some example code might 
be more useful as a starting point for these discussions...

			...jim


More information about the graphics-rasterizer-dev mailing list