Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.9.3
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
We generate field offsets twice in separate applications, the first generates the interface declarations C header, the second when building the boot image writer. As static fields can be allocated by the loading of any class, to get the same static field layout in generate interface declarations and the boot image writer we need to load the same classes in the same order. Prior to r13964 we fluked this. After r13964 we get slightly different field allocations meanings that org_jikesrvm_memorymanagers_JMTk_BasePlan_gcStatusOffset is out by 8 on ia32 Linux (I imagine similar is true on other platforms). This tricks sys.C into believing a GC is always going on and through a series of interactions inhibits any recompilation.
I believe the assumption that we can run generate interface declarations and the boot image writer as two separate applications and get the same static field offsets is fundamentally flawed. We need another approach to handle static field entry points that are exposed to the boot image runner.
Issue Links
| This issue supercedes: | ||||
| RVM-371 | 13956 broke PPC64 development build |
|
|
|
Temporary work around is to make the static field offsets non-const and then register them using a syscall during VM boot up.