Hello Ivan, What would be the criteria for freeing up the garbage collected objects in new area ?
Wont if lead to performance issues with duplication of memory ? Just wondering, - Vikram Mohan On 8/29/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
Weldon, I think there are two different tasks: 1. We need to make sure that GC doesn't break heap consistency. 2. We need to detect wrong / unreported roots from JIT/VM. First task is solved by HARMONY-881. Second task can be addressed with your proposal. The point is, that java stack can contain some garbage (slots which will never be used), this can complicate this task. I have used different approach to locate second problem: Most likely unreported roots leads to crash or at least unexpected behaviour of program. I have written special GC (customized the HARMONY-1269) which moves all objects after garbage collection to new area. Old area is marked as inaccessible (hardware protection: pages has neither read nor write permission). Failing program can be started with the GC implementation and the exact place with outdated root can be identified. -- Ivan On 8/29/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > One of the harder GC debugging problems is verifying that all live > references are indeed reported to the GC. In other words, verify the > stuff that happens outside the GC that impacts the GC. This actually > complements verifying that GC internals are functioning correctly. > Both are important for building a product quality JVM. Perhaps it > makes sense to build the following tool for Harmony: > > Build a stack scanner that scans a given Java thread and compares each > 4-byte slot to see if it can be interpreted as a ref ptr into the java > heap. Put the scan results in a list. The locations that match what > the JIT reports are removed from this list. The assumption is that > two independent approaches to identifying live references is most > likely correct. The remaining (hopefully few) items on the list can > be manually inspected by JIT and VM developers to determine if somehow > a live reference was actually overlooked. > > The above approach can be refined. More powerful filters can be > constructed to reduce the clutter of false positives. It may even be > possible to run the JVM in "debug" mode that will do an assert(0); if > it sees suspicious bit patterns in the stack. > > Thoughts? --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- www.FaeLLe.com www.VikramMohan.com
