It's a very good review. DailyProjectCoverage and DailyProjectJavaFileMetrics are similar because both are looking for snapshot of the system in a given day. It is a good point to use soft reference or even weak reference but we simply cannot do so in these two cases. I designed these two objects to hold hard reference of sensor data entries because we don't want part of sensor data entries be GCed when we compute system metrics as a complete unit. This is the general idea. Perhaps it is not the best design but reliable. And DailyProjectCoverage is soft referred so the memory will not be held forever. We can do an asynchronous design and/or code review of it in the group. How other people think?
Thanks, Hongbing ----- Original Message ----- From: Aaron Kagawa <[EMAIL PROTECTED]> Date: Saturday, November 20, 2004 0:57 am Subject: [HACKYSTAT-DEV-L:362] DailyProjectCoverage and soft references > Hey Guys, > > I have a question about soft references. But, first I must provide > you with > some background information. > > I'm working on the Project level > ProjectJavaClassWorkspaceMapManager. And > I'm investigating substituting use of the personal level > JavaClassWorkspaceMapManager with the project level manager in > DailyProjectUnitTest and DailyProjectCoverage. This is a bit of a > struggle > because the two DailyProjectData implementations are quite > different. I am > noticing that the DailyProjectUnitTest implementation is quite > simple and > elegant. On the other hand, the DailyProjectCoverage > implementation is > quite complicated and could have some problems with it. The > potential > problem I'll address now deals with Soft References. > > From what I understand the good thing about Soft References is > that even > though we have a valid Soft Reference to an object, it still can > be > GCed. Hopefully, that is right. Although, I'm not totally clear > on what > the differences between Soft and Weak References. > > In Hackystat the SensorDataCache uses a ThreeKeyCache which > provides Soft > References. So, the idea is that the DailyProjectData > implementations > should read through the SensorDataEntry's, which is obtained from > the > SensorDataCache, and create a project level representation of the > sensor > data. If space is needed and GC happens the SensorDataEntry's can > be GC'ed > no problem. (right?) > > Anyway, it appears that the DailyProjectCoverage implementation > creates a > "hard" or regular reference. Here is some code that puts a > SensorDataEntry > (in this case Coverage) into the runtimeMap, which is a TreeMap > (the code > is a little out of order, but it should show you that we are > storing > SensorDataEntry's in something other than the SensorDataCache). > > updateRuntimeMap(entry, workspaceFile); > .... > coverageWorkspaceMap.put(entry, workspaceFiles); > ... > runtimeMap.put(entry.getRunTime(), coverageWorkspaceMap); > > > So, (and this is another wild guess) this reference would > supersede the > Soft Reference and the Coverage SensorDataEntry will never be > GC'ed.. Right? Hopefully, I'm totally wrong and totally confused. > OK... > well, this isn't totally true. It turns out that the > DailyProjectCache also > uses Soft References from ThreeKeyCache and the whole > DailyProjectData > instance can be GC'ed. I believe Hongbing mentioned this a year > ago, which > one is going to be GC'ed first? It would be really cool if it was > possible > to GC the SensorDataEntries first then go up a level to the > DailyProjectData. > Anyway, I've probably confused you by now.. but the bottom line > question > is.... Is holding a collection SensorDataEntries in anything other > than the > SensorDataCache is a good idea? > > thanks, aaron > > ps.. Whoa! DailyProjectJavaFileMetric does the same thing. It > appears > that any time we have a runtime attribute in the sensor data we > are using > some sort of map to store the runtimes and the entries. > > >
