You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/08/29 03:07:43 UTC
[DRLVM][GC] proposal: tools to help verify all live references are properly enumerated
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?
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [DRLVM][GC] proposal: tools to help verify all live references are properly enumerated
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <mr...@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 <iv...@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 <we...@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
Re: [DRLVM][GC] proposal: tools to help verify all live references are properly enumerated
Posted by FaeLLe <mr...@gmail.com>.
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 <iv...@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 <we...@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
>
>
--
www.FaeLLe.com
www.VikramMohan.com
Re: [DRLVM][GC] proposal: tools to help verify all live references are properly enumerated
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <we...@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