#493 Seems to be write barrier missed in 2 dimension array

[xlhuang]

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
-X:gc:verbose=2 -Xms78M
-X:gc:variableSizeHeap=false -X:processors=1
-X:aos:enable_replay_compile=true -X:aos:cafi=/tmp/$bm.ca
-X:aos:dcfi=/tmp/$bm.dc
-X:vm:edgeCounterFile=/tmp/$bm.ec SpecApplication
$bm $bm _998_end

and the .ca and .dc file is empty. And there one method
in the
ec file, the program would die in a full heap gc:
M 22 < BootstrapCL,
Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread;,
run, ()V

    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

The hypothesis:
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
details:

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,
VM_CollectorThread.run()
is baseline compiled and an entry is allocated in the
two dimensional array.
something like
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
at 0x3243e354.

1. The new entry in the nursery was treated as garbage when
   a. the "data" pointer was not treated as a
   root. and
   b. the write barrier wasn't inserted for the
   following
   (VM_EdgeCounts.java):
   data[id] = new int[numEntries]; So
   during a full heap
   collection, when it tries to trace the entries for
   "data" array, the program
   crashed.

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
collect garbage.
Here is some details how they are allocated:
The array is data[][], so data, data[i] are two
dimension of the arrayes
In BaseAdaptiveGenMS:
data is at 0x3243e354
data[id] was 0x32495364
and new entry is 0x74f2f34c (so there should be a write
barrier...)

For FastAdaptiveGenMS,
data is at 0x45000018 (LOS space)
data[id] was at (0x331bdc94) and new entry data[id] is
at (0x74db9a6c)
(nursery).
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
for me.

[Ian Rogers]

Logged In: YES
user_id=308843
Originator: NO

Can this issue be closed?