Issue Details (XML | Word | Printable)

Key: RVM-374
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Ian Rogers
Reporter: Ian Rogers
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
RVM

Static field allocation is non-deterministic

Created: 14/Feb/08 07:48 AM   Updated: 15/Feb/08 02:41 AM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.9.3

Time Tracking:
Not Specified

Issue Links:
Supercedes
 


 Description  « Hide
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.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Ian Rogers added a comment - 14/Feb/08 08:26 AM
Temporary work around is to make the static field offsets non-const and then register them using a syscall during VM boot up.

Ian Rogers added a comment - 14/Feb/08 08:46 AM
Resolved in r13967, awaiting clean regression results before closing.

Ian Rogers added a comment - 15/Feb/08 02:41 AM
Regressions now look in order.