Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8253868

CodeSection::initialize_shared_locs buffer argument types and sizes are opaque




      The types and sizes of the buffer argument to initialize_shared_locs are inconsistent and opaque. Here is its signature

      void CodeSection::initialize_shared_locs(relocInfo* buf, int length);

      There are three problematic call sites.

      In c1_Compilation.cpp, we have

        int locs_buffer_size = 20 * (relocInfo::length_limit + sizeof(relocInfo));
        char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size);
                                              locs_buffer_size / sizeof(relocInfo));

      relocInfo::length_limit is a count of shorts, while sizeof(relocInfo) is a count of chars. The units aren't the same but are added together as if they were. relocInfo::length_limit is supposed to be the maximum size of a compressed relocation record, so why add sizeof(relocInfo)?

      In sharedRuntime.cpp, we have two places. The first:

            short buffer_locs[20];

      relocInfo::length_limit is 15 on a 64-bit machine, so with a buffer of 20 shorts, alignment in initialize_shared_locs might take up to of 3 more, which is uncomfortably close to 20 afaic. And, if you add sizeof(relocInfo) as happens in c1_Compilation.cpp, you're bang on at 20. The unstated assumption seems to be that only a single relocation record will be needed.

      The second:

            struct { double data[20]; } locs_buf;
            buffer.insts()->initialize_shared_locs((relocInfo*)&locs_buf, sizeof(locs_buf) / sizeof(relocInfo));

      Before JDK-8253375, this was:

            double locs_buf[20];
            buffer.insts()->initialize_shared_locs((relocInfo*)locs_buf, sizeof(locs_buf) / sizeof(relocInfo));

      This allocates a buffer that will hold 5 compressed relocation records with 10 bytes left over, and guarantees 8 byte alignment. Perhaps when it was written, initialize_shared_locs didn't align its buffer argument address. And, there's that sizeof(relocInfo) padding again: 2 extra bytes per relocation record.

      The reason(s) for these argument setups should be discovered and a consistent fix applied.


          Issue Links



              Unassigned Unassigned
              phh Paul Hohensee
              0 Vote for this issue
              2 Start watching this issue