Shenandoah: Enable concurrent class unloading on x86_32

[Zhengyu Gu]

On 10/15/19 11:03 AM, Roman Kennke wrote:
> It looks ok to me. Shared changes would need further reviewing upstream
> by Erik, eventually, but feel free to bake it in sh/jdk first.
> 
> I'd probably use rdi and load the thread-base into it using get_thread()
> and keep the interface cleaner. Your call.

I am going to keep current version. What you suggested, generating a lot 
more code, including a runtime call [1], vs. just a single load from 
known address.

Thanks,

-Zhengyu

[1]
  ;; nmethod_entry_barrier {
   0xe70df1ab:   push   %edi
   0xe70df1ac:   push   %eax
   0xe70df1ad:   push   %edx
   0xe70df1ae:   push   %ecx
   0xe70df1af:   call   0xf7159de0                   ;   {runtime_call 
Thread::current()}
   0xe70df1b4:   pop    %ecx
   0xe70df1b5:   pop    %edx
   0xe70df1b6:   mov    %eax,%edi
   0xe70df1b8:   pop    %eax
   ....



> 
> Roman
> 
> 
>> Prerequisites:
>>   1) Shenandoah: SBSA::load_at() should save/restore registers when
>>      calling SATB barrier [1]
>>   2) JDK-8230765: Implement nmethod barrier for x86_32 platforms [2]
>>
>>
>> (2) is upstream CR, should be reviewed here. However, there is no
>> implementation there that can exercise this implementation. I would
>> prefer to bake here for sometime, before upstreaming it.
>>
>>
>> Combined webrev:
>> http://cr.openjdk.java.net/~zgu/shenandoah/conc-class_unloading_x86_32/webrev.00/
>>
>>
>> Test:
>>    hotspot_gc_shenandoah (fastdebug and release) on Linux with x86_32 JVM.
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010681.html
>>
>> [2] http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.00/
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>
>