Porting Loom to additional architectures

[Ron Pressler]

I’ll get to cleaning up the code soon.

There’s no need to implement oopMapStubGenerator. It is not currently used, and will likely be deleted 
unless we find some use for it (it’s the result of an early implementation, abandoned once we switched 
to stack chunks).

— Ron

> On 24 Sep 2021, at 18:07, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 9/24/21 1:08 PM, Alan Bateman wrote:
>> On 24/09/2021 10:50, Aleksey Shipilev wrote:
>>> I can take a look at x86_32.
>>> 
>>> What is the usual criteria for "passing" Loom implementation? In other
>>> words, what tests should pass to say that the port is good?
>>> 
>> Eventually all tests should pass. A more targetted subset to run is
>> test/jdk/:jdk_lang
>> test/hotspot/jtreg/runtime/vthread
>> test/hotspot/jtreg/serviceability/jvmti/vthread
>> and maybe test/jdk/jdk/internal/vm/Continuation for the initial runs
>> once you have something running.
> 
> All right, thanks. I doing x86_32 here:
>  https://github.com/openjdk/loom/pull/65
> 
> x86_32 is basically a gateway for 32/64 bit cleanliness, as you can see from the multiple format string changes. If we do ARM32 port, most of this should be fixed anyway.
> 
> I also see there is plenty of commented code in the Loom files, long lines, especially around logging and asserts, etc. Since porting work would probably copy-paste some of that, I think cleaning up x86_64 code would be beneficial for everyone.
> 
> -- 
> Thanks,
> -Aleksey
>