[OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

[Jim Graham]

I'm pretty familiar with all of this code and there aren't any places 
that save the tile array that I remember.  The embedded code that Pisces 
was taken from had some caching of alpha arrays, but we didn't use or 
keep that when we converted it for use in the JDK...

It occurs to me that since you are collecting the various pieces of 
information into an object to store in the thread local storage, perhaps 
we should convert to a paradigm where an entire Tile Generation sequence 
uses that object "TileState?" as its main way to communicate info around 
the various stages.  Thus, you don't really need an int[4] to store the 
4 parameters, they could be stored directly in the TileState object. 
This would require more sweeping changes to the pipeline, but it might 
make the code a bit more readable (and make the hits to convert over 
more moot as they would be improving readability and give more focus to 
the relationships between all of the various bits of data).  Then it 
simply becomes a matter of managing the lifetime and allocation of the 
TileState objects which is a minor update to the newly refactored code.

			...jim

On 4/10/13 3:59 PM, Sergey Bylokhov wrote:
> On 4/10/13 11:46 PM, Laurent Bourgès wrote:
>>> I see that some methods which take it as argument doesn't use them. And
>>> most of the time we pass AATileGenerator and abox[] to the same
>>> methods, so
>>> it could be merged?
>>>
>> For now I did not want to modify the AAShapePipe signatures: abox[] is
>> filled by AATileGenerator implementations (ductus, pisces, others) in
>> order
>> to have the shape bounds and render only tiles covering this area.
> You still have to check all the places, where these objects are filled
> and used, and refactoring is a good start, no?
> Otherwise, how can you prove that these arrays are used as you would
> expect, These arrays could be stored like the cache or re-used for other
> purpose(if someone don't want to create new arrays).
> Probably it will be good to split all your changes / to a few CR.
>   - cleanup
>   - Some small changes which gave us most speedup
>   - all other things.
> ??
>>
>>> Also I suggest to use jmh for java micrbenchmarks.
>>> http://openjdk.java.net/**projects/code-tools/jmh<http://openjdk.java.net/projects/code-tools/jmh>
>>>
>>> So your test will be:
>>> http://cr.openjdk.java.net/~**serb/AAShapePipeBenchmark.java<http://cr.openjdk.java.net/%7Eserb/AAShapePipeBenchmark.java>
>>>
>>>
>> Thanks,
>> I will try it asap
>>
>> Laurent
>>
>>>
>>> --
>>> Best regards, Sergey.
>>>
>>>
>
>