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