Hello:
  Thanks, I find the problem, I should use Allocator.fillAlignmentGap(allocCursor, copyTo.toAddress()); to fill alignment gap between calculated copy address and allocCursor.
But another problem emerges, metaData space usage always increase during full heap collection, and finally cause memory leak. It seems that there are objectBarrier activities during GC. The following code is always called to acquire more space, but when complete trace is called, the remset seems not being flushed. Though the nursery collection works fine. The mature trace actually should not process the remset. How do I check which part of code consumes metaData space exactlly?

private void fastPath(ObjectReference src, Address slot, ObjectReference tgt, int mode) {
...

remset.insert(slot);

 
DaFENG
Coder
Telecommunication && Network Industry
Pudong
Shanghai
China



From: Robin Garner <robin.garner@anu.edu.au>
To: Discussion of day-to-day development and design among JikesRVM core team members <jikesrvm-core@lists.sourceforge.net>; "General discussion of Jikes RVM design, implementation, issues, and plans" <jikesrvm-researchers@lists.sourceforge.net>
Sent: Tue, December 22, 2009 7:56:04 AM
Subject: Re: [rvm-core] a object copying related problem

Hi Da Feng,

Try putting a watch on object 332, ie watchObject=332.

You might also try watching the relevant addresses, ie

watchAddress=0x201AFDBC,0x201AFDC0,0x201AFDC4,0x201AFDC8,0x201AFDCC

and perhaps the source addresses - the MMTk harness has a 5-word object
header, and the allocation site is in the 2nd word after the GC header.

btw, I think this is a discussion better suited to the
jikesrvm-researchers list.

cheers,
Robin


Da Feng wrote:
> Hello:
> when I copy an object to an different address, the allocation site went
> wrong.
> The collector works in way similar to Gen-MarkCompact. this happens when
> compacting mature heap. Can any one give me some clue?
> ============================
> [Full heap][GC 7 Start 3459.95 ms  1956KB [COLLECT] Computing roots for
> mutators
> [COLLECT] mutators to scan: 1
> [COLLECT] Computing roots for mutator
> [ROOTS] Tracing root 0x20040018
> [ROOTS] new value of 0x20040018
> [ROOTS] Tracing root 0x20040030
> [ROOTS] new value of 0x20040030
> [ROOTS] Tracing root 0x20040070
> [ROOTS] new value of 0x20040070
> [ROOTS] Tracing root 0x200400B0
> [ROOTS] new value of 0x200400B0
> [ROOTS] Tracing root 0x200400F0
> [ROOTS] new value of 0x200400F0
> [ROOTS] Tracing root 0x20040130
> [ROOTS] new value of 0x20040130
> [ROOTS] Tracing root 0x20040170
> [ROOTS] new value of 0x20040170
> [ROOTS] Tracing root 0x200401B0
> [ROOTS] new value of 0x200401B0
> [ROOTS] Tracing root 0x200401F0
> [ROOTS] new value of 0x200401F0
> [ROOTS] Tracing root 0x20040230
> [ROOTS] new value of 0x20040230
> [ROOTS] Tracing root 0x20040270
> [ROOTS] new value of 0x20040270
> [ROOTS] Tracing root 0x8CC23E48
> [COLLECT] Copying object [332@24:9] from 0x8CC23E48/nursery to 0x201AFDB8/mw
> [ROOTS] new value of 0x201AFDB8
> [ROOTS] Tracing root 0x201AFDB8
> [ROOTS] new value of 0x201AFDB8
> [ROOTS] Locals: 13
> [COLLECT] mutators to scan: 0
> [COLLECT] Copying object [322@24:9] from 0x8CC0BF78/nursery to 0x201B2400/mw
> [COLLECT] Copying object [323@24:9] from 0x8CC0E5C0/nursery to 0x201B4A48/mw
> [COLLECT] Copying object [324@24:9] from 0x8CC10C08/nursery to 0x201B7090/mw
> [COLLECT] Copying object [325@24:9] from 0x8CC13250/nursery to 0x201B96D8/mw
> [COLLECT] Copying object [326@24:9] from 0x8CC15898/nursery to 0x201BBD20/mw
> [COLLECT] Copying object [327@24:9] from 0x8CC17EE0/nursery to 0x201C0018/mw
> [COLLECT] Copying object [328@24:9] from 0x8CC1A528/nursery to 0x201C2660/mw
> [COLLECT] Copying object [329@24:9] from 0x8CC1CB70/nursery to 0x201C4CA8/mw
> [COLLECT] Copying object [330@24:9] from 0x8CC1F1B8/nursery to 0x201C72F0/mw
> [COLLECT] Copying object [331@24:9] from 0x8CC21800/nursery to 0x201C9938/mw
> [COLLECT] Computing roots for mutators
> [COLLECT] mutators to scan: 1
> [COLLECT] Computing roots for mutator
> [ROOTS] Tracing root 0x20040018
> [ROOTS] new value of 0x20002660
> [ROOTS] Tracing root 0x20040030
> [ROOTS] new value of 0x20002678
> [ROOTS] Tracing root 0x20040070
> [ROOTS] new value of 0x200026B8
> [ROOTS] Tracing root 0x200400B0
> [ROOTS] new value of 0x200026F8
> [ROOTS] Tracing root 0x200400F0
> [ROOTS] new value of 0x20002738
> [ROOTS] Tracing root 0x20040130
> [ROOTS] new value of 0x20002778
> [ROOTS] Tracing root 0x20040170
> [ROOTS] new value of 0x200027B8
> [ROOTS] Tracing root 0x200401B0
> [ROOTS] new value of 0x200027F8
> [ROOTS] Tracing root 0x200401F0
> [ROOTS] new value of 0x20002838
> [ROOTS] Tracing root 0x20040230
> [ROOTS] new value of 0x20002878
> [ROOTS] Tracing root 0x20040270
> [ROOTS] new value of 0x200028B8
> [ROOTS] Tracing root 0x201AFDB8
> [ROOTS] new value of 0x20000018
> [ROOTS] Tracing root 0x20000018
> [ROOTS] new value of 0x20000018
> [ROOTS] Locals: 13
> [COLLECT] mutators to scan: 0
> [COLLECT] Copying object [332@24:9] from 0x201AFDB8/mw to 0x20000018/mw
> Object 0x201AFDB8[332@24:9]<530,20000018>
> java.lang.IndexOutOfBoundsException: Index: 2444, Size: 12
>    at java.util.ArrayList.RangeCheck(ArrayList.java:547)
>    at java.util.ArrayList.get(ArrayList.java:322)
>    at
> org.mmtk.harness.lang.runtime.AllocationSite.getSite(AllocationSite.java:36)
>    at org.mmtk.harness.Mutator.getSiteName(Mutator.java:397)
>    at
> org.mmtk.harness.vm.ObjectModel.dumpObjectHeader(ObjectModel.java:747)
>    at org.mmtk.harness.vm.ObjectModel.copyTo(ObjectModel.java:422)
>    at org.mmtk.policy.MarkSwapLocal.swap(MarkSwapLocal.java:529)
>    at
> org.mmtk.plan.generational.markswap.GenMWMutator.collectionPhase(GenMWMutator.java:65)
>    at org.mmtk.plan.Phase.processPhaseStack(Phase.java:441)
>    at org.mmtk.plan.Phase.beginNewPhaseStack(Phase.java:351)
>    at
> org.mmtk.plan.StopTheWorldCollector.collect(StopTheWorldCollector.java:39)
>    at org.mmtk.harness.Collector.collect(Collector.java:275)
>    at org.mmtk.harness.Collector.run(Collector.java:172)
>    at
> org.mmtk.harness.scheduler.javathreads.CollectorThread.run(CollectorThread.java:35)
>

> DaFENG
> Coder
> Telecommunication && Network Industry
> Pudong
> Shanghai
> China
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core