Issue Details (XML | Word | Printable)

Key: RVM-39
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Peter Donald
Votes: 0
Watchers: 0
Operations

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

Generate VM_Entrypoints from annotations

Created: 14/Jun/07 12:16 AM   Updated: 11/Apr/08 09:24 AM
Component/s: Infrastructure: Build, Runtime
Affects Version/s: None
Fix Version/s: 1000

Time Tracking:
Not Specified

Issue Links:
Related
 
dependent
 


 Description  « Hide
We should be generating VM_Entrypoints from annotated source files. This reduces the chance that things will get out of synchronization and removes some clutter. (It also makes it easier to do whole code base optimizations like Object to ObjectReference change as not so many changes to track)

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Ian Rogers added a comment - 25/Jun/07 02:14 PM
Just to note, one problem with using class literals is that if we use a class literal for an architecture specific class (for example org.jikesrvm.ppc.VM_Registers) then when we java to bytecode compile the class with the class literal in it, we will also java to bytecode compile the class referenced by the literal. When we generate the primordials list (from the .class files created during java to bytecode compilation) we will catch this class and end up compiling at boot image writing time classes we don't intend to. The smallest problem being that these classes contain magic methods that are architecture specific.

Peter Donald added a comment - 10/Jul/07 11:47 PM
Attempted to do this today by introducing a annotation that marks fields that are unconditionally entrypoints. Unfortunately initial attempts using apt had a number of problems (the least of which is that it would require updating ant versions, and that it would bind very tightly to Suns JVM). Then attempted to use Spoon but it the in memory representation is huge and we ran into OOM problems that would only be exacerbate existing problems on 64-bit architectures. Spoon also had a few problems with some of our source files (didn't manage to determine which was causing load error).

As a result giving up on this for now.