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);
  code->insts()->initialize_shared_locs((relocInfo*)locs_buffer,
                                        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];
      buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs,
                                             sizeof(buffer_locs)/sizeof(relocInfo));

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.