Jim, 2015-03-18 23:03 GMT+01:00 Jim Graham <james.gra...@oracle.com>:
> > > On 3/18/15 2:50 PM, Jim Graham wrote: > >> On 3/18/15 9:17 AM, Laurent Bourgčs wrote: >> >>> -------- Here are some "things to consider later" --------- >>> >>> I just realized the main case where we want to deal with cleaning >>> out dirty arrays and it would be the crossings accumulation arrays. >>> It seems to me that those are special cases and so we should >>> concentrate the cleaning code on those explicitly and not have a >>> global "lets clean all arrays everywhere" setting. >>> >>> Agreed. >>> Let's clarify my approach in marlin: it uses mainly reused arrays (int, >>> byte, float) => no allocation (GC overhead). >>> To achieve the best performance, it only clears dirty parts ie used ones >>> (see the many used mark fields). >>> >>> Dirty arrays are named "dirty" to indicate that these arrays are used in >>> a "unsafe" manner ie never zero-filled (always junk). It means the code >>> must be good enough to always set values and get those that have be set. >>> >> >> Perhaps a naming convention for the variable so that we can spot code >> that might rely on cleared data being used on an array that isn't >> necessarily cleared then? >> > > Thinking more about this - actually all arrays are (potentially) used in a > dirty manner. Some arrays naturally wouldn't care if the data is dirty > because they are filled from the start and only access the part that is > filled. Others like the coverage accumulation arrays may be more randomly > accessed and so having a predefined start state is important to them. > > So, all arrays would qualify as "dirty" as per your description unless I'm > missing something...? As you pointed, 90% arrays can be considered "dirty" and I tried to add a comment like "// dirty" (maybe I forgot some of them): I think it is a very good idea to adopt a convention like array_d ... However, there are zero-filled arrays (of course) for important reasons: - coverage / tile accumulator (alpharow, touchedTile) - growable arrays that need to be zero-filled (edgeBuckets, edgeBucketCounts) - growable arrays can exceed their initial array capacity => they use ...ArrayCache and these must stay "clean": zero-filled in put() for the dirty range [from, usedMark] I advocate it is a bit tricky and looks like C (unsafe) than java code. To conclude, it is maybe more important to indicate "clean" arrays than dirty ones... Laurent
