Hi Laurent,
I finally got the Marlin rasterizer integrated into the JDK9 client repo.
I fat-fingered the first integration and forgot to include "-u lbourges"
so Phil and Kevin and I sat on the phone and created a backout/reapply
fix and pushed them with the proper attributions, so if you see
Hi Laurent,
On 11/23/15 9:02 AM, Laurent Bourgès wrote:
I know that Marlin is slightly slower than ductus for shape size ~ 20:
Ductus seems using 16x16 blocks whereas Marlin uses 32x32 tiles so the
new RLE approach is not in use (raw encoding) i.e. lots of zero-fill /
array copy operations.
Wh
Hi Laurent,
On 11/23/15 1:35 PM, Laurent Bourgès wrote:
It seems you are right: there is a potential remaining failure !
I tested my code in CrashTest but it passed as the off heap growth
exponentially ie the mentioned case never happened !
Yes, I believe that the growth algorithms make this a
Hi Jim,
Sorry I sent the message partially edited by mistake.
> The point is that the hard failure is a condition of when we need more
than we can provide, not when we "already have" more than we can provide.
needSize should cause the hard failure, not the current size. And if
needSize is going
Hi Jim,
>> I'm code reading now:
>>
>> ArrayCache.java, line 205 - should that be needSize there? Also,
>> should these tests be > or >=?
>>
>> I wanted to limit the size to 2M (Integer.MAX_VALUE) but it wanted 2
>> passes: first, return 2M, then if more needed, fail !
>> If prefer us
Jim,
Here are few answers to several questions during last friday's sprint:
> I ran a bunch of tests on 4.2 and saw no issues and the performance looked
> good. There were still some things that Ductus was faster on, but I just
> did a brief run of a few tests I cobbled together so I don't know
