Generate VM_Entrypoints from annotations

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 1000
  • Component/s: Infrastructure: Build, Runtime
  • Labels:
    None

Description

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)

Issue Links

is depended upon by

Improvement - An improvement or enhancement to an existing feature or task. RVM-72 NonMoving annotations for classes instances of which should be allocated to the immortal heap

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Improvement - An improvement or enhancement to an existing feature or task. RVM-68 Modify VM_EntryPoints to use class literals rather than string literals

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment -

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.

Show
Ian Rogers added a comment - 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.
Hide
Permalink
Peter Donald added a comment -

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.

Show
Peter Donald added a comment - 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Peter Donald
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: