RVM

Clean up handling of JTOC

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.9.2
  • Fix Version/s: 3.0
  • Component/s: Runtime
  • Labels:
    None
  • Number of attachments :
    3

Description

Some code still assumes that the JTOC is not a constant. This adds noise to the code and creates confusion; as well, it can be an impediment when adding new code. In this improvement I will clean up the JTOC situation as much as possible, making it so that the native code assumes that it is a constant value that it acquires immediately upon loading, while the Java code has it as a baked-in constant. Notably, the baseline compiler on IA32 will no longer generate code to load the JTOC from the VM_Processor, and the VM_Processor will no longer have a JTOC field.

  1. Text File
    fix_jtoc.patch
    29/Apr/08 9:51 PM
    80 kB
    Filip Pizlo
  2. Text File
    soo.txt
    14/May/08 4:53 PM
    0.5 kB
    Filip Pizlo
  3. Text File
    workinprogress4.patch
    27/Apr/08 1:24 PM
    99 kB
    Filip Pizlo

Issue Links

is duplicated by

Improvement - An improvement or enhancement to an existing feature or task. RVM-25 Baseline compiler improvements

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • 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-161 Copy Elimination

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

Task - A task that needs to be done. RVM-382 Integration of Jikes RVM and JNODE

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
relates to

New Feature - A new feature of the product, which has yet to be developed. RVM-324 Implement class unloading

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

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

This supercedes sourcefourge tracker 1571462 [1].

[1] http://sourceforge.net/tracker/index.php?func=detail&aid=1571462&group_id=128805&atid=712771

Show
Ian Rogers added a comment - This supercedes sourcefourge tracker 1571462 [1] . [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1571462&group_id=128805&atid=712771
Hide
Permalink
Ian Rogers added a comment -

Apologies, the real issue was closed - 1207781 [1].

[1] http://sourceforge.net/tracker/index.php?func=detail&aid=1207781&group_id=128805&atid=712771

Show
Ian Rogers added a comment - Apologies, the real issue was closed - 1207781 [1] . [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1207781&group_id=128805&atid=712771
Hide
Permalink
Ian Rogers added a comment -

In the B2 compiler the registers are divided into being used for the stack, local variables and temporaries. Performing the copy elimination which is tracked by RVM-161.

Show
Ian Rogers added a comment - In the B2 compiler the registers are divided into being used for the stack, local variables and temporaries. Performing the copy elimination which is tracked by RVM-161 .
Hide
Permalink
Filip Pizlo added a comment -

Hmmm. I hope that I didn't make things unnecessarily complicated by opening a new issue when there are others that are somewhat similar. But it should be noted that this issue is greater than just the baseline compiler - I'm also cleaning up other places (notably, the C and assembly code in tools/bootImageRunner) where the JTOC is being passed around unnecessarily given that the native code also at all times knows the JTOC anyway via a global variable. The baseline compiler fix that I will perform will be minor, and will likely not have a big impact on the work of RVM-161.

For me the bigger issue is that for my native threading prototype I found places where I'd either have to continue to humor the infrastructure by passing the JTOC as if it was variable, or I could just clean the system up and not have a variable JTOC. This patch-in-progress represents the latter.

Show
Filip Pizlo added a comment - Hmmm. I hope that I didn't make things unnecessarily complicated by opening a new issue when there are others that are somewhat similar. But it should be noted that this issue is greater than just the baseline compiler - I'm also cleaning up other places (notably, the C and assembly code in tools/bootImageRunner) where the JTOC is being passed around unnecessarily given that the native code also at all times knows the JTOC anyway via a global variable. The baseline compiler fix that I will perform will be minor, and will likely not have a big impact on the work of RVM-161 . For me the bigger issue is that for my native threading prototype I found places where I'd either have to continue to humor the infrastructure by passing the JTOC as if it was variable, or I could just clean the system up and not have a variable JTOC. This patch-in-progress represents the latter.
Hide
Permalink
Ian Rogers added a comment -

I think it's a good idea to clean this up. It's been a long standing issue and we haven't cleaned it up other than in the compiler for B2. I just wanted to make sure it linked properly into all the issues we have and have had going for this.

Show
Ian Rogers added a comment - I think it's a good idea to clean this up. It's been a long standing issue and we haven't cleaned it up other than in the compiler for B2. I just wanted to make sure it linked properly into all the issues we have and have had going for this.
Hide
Permalink
Ian Rogers added a comment -

An aside if you're cleaning up the C code is RVM-79, we're dumping the wrong floating point registers. We need to change the processing of the context to pick up the XMM registers instead/as well.

Show
Ian Rogers added a comment - An aside if you're cleaning up the C code is RVM-79 , we're dumping the wrong floating point registers. We need to change the processing of the context to pick up the XMM registers instead/as well.
Hide
Permalink
Filip Pizlo added a comment -

Just an update ... I got this working on IA-32. Now I'm going to make sure that PPC is not broken. I include the current patch, in case anyone wants to see where I am so far.

Show
Filip Pizlo added a comment - Just an update ... I got this working on IA-32. Now I'm going to make sure that PPC is not broken. I include the current patch, in case anyone wants to see where I am so far.
Hide
Permalink
Ian Rogers added a comment -

Hi Filip, the patch is looking good! I wonder if there isn't a bit of creep coming into it though. For example, changing all the references in the x86 assembler of Offset to Address is distinct work from the valuable removal of the JTOC. Also, beware that some of the C interfaces are the way they are to help build on AIX. If you can help the person who will eventually apply the patch to the trunk by trying to make distinct patches it'd be appreciated. There are some notes in the wiki and doing local version management:
http://jikesrvm.org/Get+The+Source
As a SoC student you will be given write permissions to SVN branches, so this will also help.

Show
Ian Rogers added a comment - Hi Filip, the patch is looking good! I wonder if there isn't a bit of creep coming into it though. For example, changing all the references in the x86 assembler of Offset to Address is distinct work from the valuable removal of the JTOC. Also, beware that some of the C interfaces are the way they are to help build on AIX. If you can help the person who will eventually apply the patch to the trunk by trying to make distinct patches it'd be appreciated. There are some notes in the wiki and doing local version management: http://jikesrvm.org/Get+The+Source As a SoC student you will be given write permissions to SVN branches, so this will also help.
Hide
Permalink
Filip Pizlo added a comment -

Separating the assembler changes is reasonable. I'll do that once I get the PPC side to work.

Show
Filip Pizlo added a comment - Separating the assembler changes is reasonable. I'll do that once I get the PPC side to work.
Hide
Permalink
Filip Pizlo added a comment -

Patches separated - a well-cooked patch on the assembler is submitted under RVM-469.

Show
Filip Pizlo added a comment - Patches separated - a well-cooked patch on the assembler is submitted under RVM-469 .
Hide
Permalink
Filip Pizlo added a comment -

Included is a seemingly working patch. It works on IA32 and PPC. Only tested on Linux, but I think I was careful with the AIX issues.

Show
Filip Pizlo added a comment - Included is a seemingly working patch. It works on IA32 and PPC. Only tested on Linux, but I think I was careful with the AIX issues.
Hide
Permalink
Filip Pizlo added a comment -

NOTE: this patch will not work without the patch in RVM-469

Show
Filip Pizlo added a comment - NOTE: this patch will not work without the patch in RVM-469
Hide
Permalink
David Grove added a comment -

patch committed with minor adjustments due to code changes since patch submitted in r14228.

Show
David Grove added a comment - patch committed with minor adjustments due to code changes since patch submitted in r14228.
Hide
Permalink
David Grove added a comment -

reopening so I can modify fix target to 3.0

Show
David Grove added a comment - reopening so I can modify fix target to 3.0

People

  • Assignee:
    David Grove
    Reporter:
    Filip Pizlo
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
2d
Original Estimate - 2 days
Remaining:
2d
Remaining Estimate - 2 days
Logged:
Not Specified
Time Spent - Not Specified