JDK-8209586 : AARCH64: SymbolTable changes throw assert on aarch64
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: linux
- CPU: aarch64
- Submitted: 2018-08-16
- Updated: 2018-08-22
- Resolved: 2018-08-17
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 12 |
|---|
12 b08Fixed  |
Related Reports
|
Duplicate :
|
|
|
Relates :
|
|
|
Relates :
|
Description
JDK-8195100 introduces an assert that does comparisons between jbyte and char:
assert(sym->byte_at(i) == _name[i],
"%s [%d,%d,%d]", where, i, sym->byte_at(i), _name[i]);
This fails with:
assert(sym->byte_at(i) == _name[i]) failed: operator()() [0,-17,239]
sym->byte_at(i) returns a jbyte, _name is an array of char.
jbyte is a "signed char", however on aarch64 "char" is unsigned.
The assertion is tripping because while the bits match, it is a comparison between an unsigned and a signed char.
An obvious fix is to change the assertion to cast to make the types match. However, if there are other comparison operations, it might be better to change the definition of on off the strings.