It's on PowerPC. Using BaseAdaptiveGenMS configuration.
I tried on cvs head of Sep 5th and cvs head of July
19th, they both have the same problem.
How to regenerate it:
Here is the command line:
bm=_213_javac; rvm -X:gc:fullHeapSystemGC=true
$bm $bm _998_end
and the .ca and .dc file is empty. And there one method
ec file, the program would die in a full heap gc:
M 22 < BootstrapCL,
9 forwbranch < 1, 88 > 1.1235955% taken 63 forwbranch < 0, 88 > 0.0% taken 87 forwbranch < 0, 88 > 0.0% taken 110 forwbranch < 0, 88 > 0.0% taken 116 forwbranch < 85, 3 > 96.59091% taken 128 forwbranch < 3, 0 > 100.0% taken 138 forwbranch < 0, 0 > Never Executed 154 forwbranch < 0, 88 > 0.0% taken 196 forwbranch < 0, 88 > 0.0% taken 219 forwbranch < 88, 0 > 100.0% taken 236 backbranch < 88, 88 > 50.0% taken
It seems write barrier is not inserted for two
dimensional array (or GC
missed a root object when it is allocated in
bootimage). Here are the
1, in JikesRVM, it uses a two dimensional array for
edge profiles. First
dimension is the method id, second dimension is the
frequency of each branch
in that method.
2, during bootimage build, for BaseAdaptiveGenMS,
is baseline compiled and an entry is allocated in the
two dimensional array.
data[methodID] = new int[number of branch profile
entries for the method];
3, when we used an edge profile for
VM_CollectorThread.run(), the new
profile will replace the original entry. I studied the
address, the original
entry is allocated in boot image (0x32494fd4) and the
new entry is innursery (0x74f2f34c). The "data" root is
step 4 is just my hypothesis. When use FastAdaptive config,
there is an increase of edge profile right after the
program starts. So now
the edge profile array moved to LOS space instead of
boot image space.
I would guess that current GC has no problem tracing
through LOS space and
Here is some details how they are allocated:
The array is data, so data, data[i] are two
dimension of the arrayes
data is at 0x3243e354
data[id] was 0x32495364
and new entry is 0x74f2f34c (so there should be a write
data is at 0x45000018 (LOS space)
data[id] was at (0x331bdc94) and new entry data[id] is
So it seems the write barrier code is missing (or GC
lost "data" as one of
the root when "data" is in the bootimage).
The temporary fix to this seems to be: Instead of
replacing the original
edge profile entry by creating a new array, we just
replace the data in the
original array with the values in our profile. It works
Log in to post a comment.