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 <[EMAIL PROTECTED]> 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 <[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? > -- www.FaeLLe.com www.VikramMohan.com
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
