RFR: 8170106: AArch64: Multiple JVMCI issues

Andrew Haley aph at redhat.com
Mon Nov 21 16:33:28 UTC 2016


On 21/11/16 16:29, Roland Schatz wrote:
> Hi,
> 
>> @@ -110,10 +110,11 @@
>>        * @param encoding the target machine encoding for the register
>>        * @param name the mnemonic name for the register
>>        * @param registerCategory the register category
>>        */
>>       public Register(int number, int encoding, String name, RegisterCategory registerCategory) {
>> + assert number < 64;
>>           this.number = number;
>>           this.name = name;
>>           this.registerCategory = registerCategory;
>>           this.encoding = encoding;
>>       }
> Looks like debug leftover. This is in plattform independent code, I 
> don't think we should restrict the number of registers allowed for a 
> single platform.

No!  <blushes>

>>   void CodeInstaller::pd_patch_OopConstant(int pc_offset, Handle constant, TRAPS) {
>>     address pc = _instructions->start() + pc_offset;
>>     Handle obj = HotSpotObjectConstantImpl::object(constant);
>>     jobject value = JNIHandles::make_local(obj());
>> - if (HotSpotObjectConstantImpl::compressed(constant)) {
>> - int oop_index = _oop_recorder->find_index(value);
>> - RelocationHolder rspec = oop_Relocation::spec(oop_index);
>> - _instructions->relocate(pc, rspec, 1);
>> - Unimplemented();
>> - } else {
>> - NativeMovConstReg* move = nativeMovConstReg_at(pc);
>> - move->set_data((intptr_t) value);
>> + MacroAssembler::patch_oop(pc, (address)obj());
>>       int oop_index = _oop_recorder->find_index(value);
>>       RelocationHolder rspec = oop_Relocation::spec(oop_index);
>>       _instructions->relocate(pc, rspec);
>> - }
>>   }
> This is now ignoring the `HotSpotObjectConstantImpl::compressed` field.
>
> Looks like the `MacroAssembler::patch_oop` function does the correct 
> thing based on what instruction `pc` points to. I think we should put an 
> assertion in here that checks whether the flag is correct. I guess in a 
> product build it's ok to swallow this kind of error, but in a fastdebug 
> build I think we should fail if the compiler produces mismatching 
> instructions and data patches. It makes debugging the compiler a lot 
> easier...

Sure, I could add an assertion for that.

Andrew.




More information about the hotspot-compiler-dev mailing list