-
Enhancement
-
Resolution: Unresolved
-
P4
-
16
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));
BeforeJDK-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.
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
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.
- duplicates
-
JDK-8255523 Clean up temporary shared_locs initializations
- Closed
- relates to
-
JDK-8255523 Clean up temporary shared_locs initializations
- Closed
-
JDK-8253375 OSX build fails with Xcode 12.0 (12A7209)
- Resolved