harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][GC] proposal: tools to help verify all live references are properly enumerated
Date Mon, 04 Sep 2006 13:08:49 GMT
We _don't need_ the GC to be the default (performance) GC. This GC can
be bundled as separate GC.dll and used when we expect problems in
VM/JIT enumeration code.

Verification will decrease performance anyway. There is no need to
free garbage collected objects in new area: only live objects is
copied to new area. Old area is marked as inaccassible and memory
pages are invalidated (freed). Every GC accessible part of heap is
moved into upper addresses with overlapping on allocated heap limit.

As for performance: it is decreased due to whole live objects evacuation.
As for memory consumption: used memory increased during GC by the size
of all live objects. Generally, heap is greater then the live objects
size, so increase is less then 2 times.

--
Ivan

On 9/4/06, FaeLLe <mrbillcollector@gmail.com> wrote:
> 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?
> >
> --
> www.FaeLLe.com
> www.VikramMohan.com

---------------------------------------------------------------------
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


Mime
View raw message