On Thu, Mar 12, 2009 at 3:49 PM, Eddie Epstein <eaepst...@gmail.com> wrote: > On Thu, Mar 12, 2009 at 12:14 PM, Adam Lally <ala...@alum.rpi.edu> wrote: >> The next question is under what conditions would a GC execute. >> Requiring an explicit call seems counter to what other garbage >> collecting runtime environments do, and like Thilo I'm confused about >> who would call this and when. I think it would be better to define >> the parameters that control GC in the PerformanceTuningSettings that >> we already have, and make them dependent on how much CAS heap space is >> used relative to a GC threshold that the user has set in the >> PerformanceTuningSettings. > > Given the current CAS implementation, GC related operations are going to > be fairly expensive, for example, even just computing how much data is > available to be deleted. So I'd be concerned that any automatic GC based > on CAS size or other dynamic properties may often be CPU costly. > > One user scenario that motivated this thread was that an aggregate designer > knew exactly when they wanted to do GC. What is wrong with giving them > a CAS method to call? >
Where would they call this method from? An aggregate designer would just write a descriptor, not code. I suppose they could stick in a "GC annotator" that does nothing but call the GC method, but this seems like a hack. Can this be handled with configuration? I think somebody suggested something like this already, but I can't find the quote right now. One of the GC configuration options would be to specify that a GC should always occur after a particular delegate AE has finished (or that GC should occur after that AE finished, if the heap size is also above a certain threshold). -Adam
