|
[
Permlink
| « Hide
]
David Grove added a comment - 30/May/08 07:11 AM
My impression was that putting it in a separate space was intentionally, since it has different access characteristics than normal bootimage objecrs.
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.
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. 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.
As I said, feel free to change it if it is a high priority issue for you.
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)
looks to me like this is a won't fix, but feel free to re-open. (doing jira housecleaning...)
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.
It has different locality properties than the objects in the data segment. Even if it becomes an object, we should keep it separate segment.
|
||||||||||||||||||||||||||||||||||||||||||
 |
|
Wish
Reopened
Major
Make the root map an object
