Hello porters,

I am currently working on a large change that intends to replace the current 
stack-locking with a new fast-locking scheme that is not racy on object 
headers. The primary reason for making that change is to enable Lilliput (where 
we cannot really deal with stack-locking without severely impacting performance 
in other places, even non-locking code-paths, e.g. GCs). Find details in the 
draft PR:

https://github.com/openjdk/jdk/pull/9680

I need help with some of the ports:
- I took care of x86_64, x86_32 and aarch64 myself, and fully implemented 
fast-locking there.
- I also fixed arm, ppc, s390 and zero in so far that I removed stack-locking, 
and use heavy monitors always. This is not a totally unreasonable choice. I 
found out that stack-locking really only helps in rather narrow scenario: 
Stack-locking (and this new fast-locking scheme) are only useful when an 
application: 1. Uses lots of uncontended (single-threaded) synchronized (as 
happen when using legacy collections like Vector) *and* 2. Churns a lot of such 
locks. I.e. it is ok for heavy monitors to allocate a single Vector and then 
often calls methods on it using a single thread, but it is bad if the 
application keeps allocating new StringBuffers, only to call one method on 
them. The latter scenario is where stack-locking and the new scheme help shave 
off a lot of monitor traffic - and sadly this is still a concern for a few 
workloads. But it also means that it may be completely ok for a port to not 
bother and always use heavy monitors. If you would like to fully implement 
fast-locking in your port, you may want to do that now and I'll add it to the 
PR, or you can do that later as a follow-up change once the fast-locking is 
approved and integrated.

- I have not worked with the riscv port yet, and that is where I need help most 
urgently, because it breaks the build and GHA. I would appreciate if 
maintainers could have a look and do the minimal changes to remove 
stack-locking and always fall back to heavy monitors. You could look at one of 
the other ports to see how to do that.

Let me know if you have any questions that the PR or this email doesn't answer.

Thank you,
Roman





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


Reply via email to