Wait a minute! I missed something. Actually, there is no need to track allocations in the young generation! Only survivals. So, you apply the boolean trick only for objects that survive the nursery collection.
So, there would be no bit overhead in objects, nor work overhead on allocations. Just a little overhead on moving objects across generations. As for the class loader, there are many solutions; one is to maintain a list of loaded classes with surviving objects. Every time a class sets one of its gc-area booleans to false (at the end of a gc cycle), it checks whether all its other gc-area booleans are also false. If yes, it removes itself from the class-loader "loaded class with surviving objects" list. When this list becomes empty, the class loader can be unloaded (as soon as it is not referenced elsewhere). Making any sense? Etienne Etienne Gagnon wrote: > Ivan Volosyuk wrote: > >>If I understand you correctly, you suggest to increment >>per-classloader object counter on allocation... It can be much >>overhead with the solution, as most of the objects die young. >>Do I miss something? > > > No, I was thinking about a "per-class" counter. Actually, a counter is > not needed. A simple boolean is suffucient (one boolean per gc > generation in each class), so the cost would be a single inconditional > memory write per object allocation. I would think that this would be > lost in the noize of object field "zero" initialization. No? > > Etienne > -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
