RVM
  1. RVM
  2. RVM-522

Make the root map an object

    Details

    • Type: Wish Wish
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Infrastructure: Build, MMTk
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Currently the root map is paged into memory and accessed using addresses [1]. There doesn't seem to be a good reason why the root map couldn't be represented using a byte array and held in the data image, which imo would be more in the spirit of a Java-in-Java VM. It would require allocating and creating the root map at the end of writing the boot image in memory and then having an extra copy of the root map into the boot image once it was computed. We already do a similar job for the boot record. It needs to be at the end of the image as we don't know its length.

      [1] http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/MMTk/ext/vm/jikesrvm/org/jikesrvm/mm/mmtk/ScanBootImage.java?revision=14232&view=markup

        Activity

        Hide
        David Grove added a comment -

        My impression was that putting it in a separate space was intentionally, since it has different access characteristics than normal bootimage objecrs.

        Show
        David Grove added a comment - My impression was that putting it in a separate space was intentionally, since it has different access characteristics than normal bootimage objecrs.
        Hide
        Ian Rogers added a comment -

        Its a randomly accessed list of bytes.. the random access is needed so that chunks can be skipped in the event that it is executing in parallel. I can't see why this shouldn't be a byte array other than the TLC it'll require to get this to work with the boot image writer.

        Show
        Ian Rogers added a comment - Its a randomly accessed list of bytes.. the random access is needed so that chunks can be skipped in the event that it is executing in parallel. I can't see why this shouldn't be a byte array other than the TLC it'll require to get this to work with the boot image writer.
        Hide
        Steve Blackburn added a comment -

        It would be trivial to make it an array. It was separated as a conscious design decision. I'm not going to die in a ditch over this, but it seemed to me that it is a special case, just as the code arrays are. 1. The root map is metadata; it describes the boot image. 2. Nor do we ever access it as a Java object because we can't afford the array bounds check. 3. Finally it is very large, with its size proportional to the boot image.

        None of these things make it difficult to implement within the boot image, but they may explain why I wanted to keep it separate.

        If this is a high priority for someone and they wish to reimplemented within the boot image, and do so without incurring performance overheads (due to array bounds checks, for example), that's OK with me. It's not the top of my priority list though, and it it is certainly not the way it is through laziness or lack of TLC; it was done that way deliberately.

        Show
        Steve Blackburn added a comment - It would be trivial to make it an array. It was separated as a conscious design decision. I'm not going to die in a ditch over this, but it seemed to me that it is a special case, just as the code arrays are. 1. The root map is metadata; it describes the boot image. 2. Nor do we ever access it as a Java object because we can't afford the array bounds check. 3. Finally it is very large, with its size proportional to the boot image. None of these things make it difficult to implement within the boot image, but they may explain why I wanted to keep it separate. If this is a high priority for someone and they wish to reimplemented within the boot image, and do so without incurring performance overheads (due to array bounds checks, for example), that's OK with me. It's not the top of my priority list though, and it it is certainly not the way it is through laziness or lack of TLC; it was done that way deliberately.
        Hide
        Ian Rogers added a comment -

        I think it is a poor design decision. Everything in the code image is an object, they have headers, lengths, we can manipulate them and pass around their object references. The data image is similar except you need two sets of glasses to look at the JTOC. For native code we can inspect it using a library like bfd (this would be nice for more verbose native stack traces). The root map on the other hand is only intelligible to the scan boot image code. If we wanted to inquire about the root map over say a JDWP debug connection, this wouldn't be possible. Currently the root map is only accessible through raw address accesses to memory, the main other place we have to handle data like this is JNI, but that was out of our hands.

        Show
        Ian Rogers added a comment - I think it is a poor design decision. Everything in the code image is an object, they have headers, lengths, we can manipulate them and pass around their object references. The data image is similar except you need two sets of glasses to look at the JTOC. For native code we can inspect it using a library like bfd (this would be nice for more verbose native stack traces). The root map on the other hand is only intelligible to the scan boot image code. If we wanted to inquire about the root map over say a JDWP debug connection, this wouldn't be possible. Currently the root map is only accessible through raw address accesses to memory, the main other place we have to handle data like this is JNI, but that was out of our hands.
        Hide
        Steve Blackburn added a comment -

        As I said, feel free to change it if it is a high priority issue for you.

        Show
        Steve Blackburn added a comment - As I said, feel free to change it if it is a high priority issue for you.
        Hide
        Steve Blackburn added a comment -

        If you do do this, and as I understand it, your biggest objection is to the fact that it is not an object, then I suggest you keep the root map as a separately mmapable file and throw a header on the front (whcih will be trivial). Then you'll need to just ensure that it is accessed without array bounds checks (or read barrier, if we were ever to implement byte array read barriers)

        Show
        Steve Blackburn added a comment - If you do do this, and as I understand it, your biggest objection is to the fact that it is not an object, then I suggest you keep the root map as a separately mmapable file and throw a header on the front (whcih will be trivial). Then you'll need to just ensure that it is accessed without array bounds checks (or read barrier, if we were ever to implement byte array read barriers)
        Hide
        David Grove added a comment -

        looks to me like this is a won't fix, but feel free to re-open. (doing jira housecleaning...)

        Show
        David Grove added a comment - looks to me like this is a won't fix, but feel free to re-open. (doing jira housecleaning...)
        Hide
        Ian Rogers added a comment -

        I feel the metacircularity of Jikes RVM is spoilt by the root map not being an object. We do have non-objects in the RVM, the results of mmap calls being the main example. I think long term we should aim to get the root map into the data image as I don't see it as distinct. The current approach is convenient.

        Show
        Ian Rogers added a comment - I feel the metacircularity of Jikes RVM is spoilt by the root map not being an object. We do have non-objects in the RVM, the results of mmap calls being the main example. I think long term we should aim to get the root map into the data image as I don't see it as distinct. The current approach is convenient.
        Hide
        David Grove added a comment -

        It has different locality properties than the objects in the data segment. Even if it becomes an object, we should keep it separate segment.

        Show
        David Grove added a comment - It has different locality properties than the objects in the data segment. Even if it becomes an object, we should keep it separate segment.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ian Rogers
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: