On Fri, 11 Nov 2022 16:16:18 GMT, Erik Österlund <eosterl...@openjdk.org> wrote:
> The current loom code makes some assumptions about GC that will not work with > generational ZGC. We should make this code more GC agnostic, and provide a > better interface for talking to the GC. > > In particular, > 1) All GCs have a way of encoding oops inside of the heap differently to oops > outside of the heap. For non-ZGC collectors, that is compressed oops. For > ZGC, that is colored pointers. With generational ZGC, pointers on-heap will > be colored and pointers off-heap will be "colorless". So we need to > generalize encoding and decoding of oops in the heap, for loom. > > 2) The cont_oop is located on a stack. In order to access it we need to > start_processing on that thread, if it isn't the current thread. This > happened to work so far for ZGC, because the stale pointers had enough > colors. But with generational ZGC, these on-stack oops will be colorless, so > we have to be more accurate here and ensure processing really has started on > any thread that cont_oop is used on. To make life a bit easier, I'm moving > the oop processing responsibility for these oops to the thread instead. > Currently there is no more than one of these, so doing it lazily per frame > seems a bit overkill. > > 3) Refactoring the stack chunk allocation code > > Tested with tier1-5 and manually running Skynet. No regressions detected. We > have also been running with this (yet a slightly different backend) in the > generational ZGC repo for a while now. Nice to have PR 11111. It's gonna take a long time until we see 111111. ------------- PR: https://git.openjdk.org/jdk/pull/11111
