harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FaeLLe <mrbillcollec...@gmail.com>
Subject Re: [DRLVM][GC] proposal: tools to help verify all live references are properly enumerated
Date Sun, 03 Sep 2006 21:31:27 GMT
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 <ivan.volosyuk@gmail.com> 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 <weldonwjw@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message