GC infrastructure

[graalvmbot]

Provides infrastructure that simplifies the integration of HotSpot garbage collectors (like Shenandoah) into Native Image. Each commit in this PR can be reviewed on its own.

[christianhaeubl]

@simonis : this PR provides the C++ infrastructure that simplifies the integration of HotSpot garbage collectors (like Shenandoah) into Native Image. Note that the first commit ("Remove unnecessary files") can't be opened on GitHub (the diff is probably too large).

While I am working on the Java glue code, the interface between the C++ code and Native Image may continue to change a bit. So, I will probably force-push a few times to this branch.

[simonis]

Hi @christianhaeubl ,

I'm starting to look into this more closely and have some questions:

1. In the README.md you write that the "mocks/: Contains autogenerated mocks for all deleted C/C++ headers". It currently also contains all the Shenandoah headers. Is my assumption right, that once I move start to move them over to share/gc/shenandoah/ I have to remove them from the mocks/ directory?
2. Most of the header files under mocks/ are empty but some of them contain include directives. It seems that they are for include files which are present in either their canonical location or under svm/. Is that correct? Is that also true the other way round, i.e. every non-deleted header file is still referenced from header files under mock/ if it was originally referenced from those files?
3. It looks like the files under svm/ still contain SVM #ifdef/#ifndefs. I thought that the svm/ directory only contains SVM-specific code anyway, so why are those ifdefs/ifndefs needed? Is this just a historical leftover from a time when it was tried to make those files easily mergeable with their original counterparts?
4. Is my understanding correct, that for files which are kept under their original HotSpot path, we try to keep changes to a minimum and rather use #ifdef``#ifndef SVM? What's the rule of thumb for when to leave a file under it's original path and moving it to svm/? Just personal judgement?
5. Is my assumption correct that everything that is supposed to end up in the native GC library should be in the svm_gc namespace? What sense does the following code make:

#ifndef SVM
namespace svm_gc {

Is this just a pointless artifact that we can ignore?

More to follow :)

[christianhaeubl]

Regarding 1:
Yes, it is considered best practice to remove the corresponding mocks once you move the actual files into their location. This especially improves filename-based navigation in most IDEs. For the build, it shouldn't really matter because the mocks directory is last on the include path.

Regarding 2:
We keep the original include directives in the mocks to avoid unnecessary #ifdefs in the original files. Otherwise, we would for example see missing type errors if types are only included transitively. The includes in the mocks are resolved against either their standard location or the files under svm/. So, yes, this also means that non-deleted header files are referenced from mocks if the original file did the same.

Regarding 3:
Files under svm/ fall into two categories:

• Files closely tracking OpenJDK code (e.g., nmethod.cpp): for such files, SVM needs to implement the same "interface" as the OpenJDK, so we sometimes use #ifdefs to make it clearer which parts are identical to the OpenJDK and which parts are SVM-specific. This primarily makes updating easier (i.e., diffing/merging with the OpenJDK sources).
• Fully custom implementations (e.g., svmOopMap.hpp): in those files #ifdefs are unnecessary.

Regarding 4:
Yes, for files that remain in their original OpenJDK paths, we try to keep the modifications to a minimum and rather put all SVM-specific changes behind #ifdefs. This makes updating a lot easier as most of those #ifdefs will be merged without conflicts. Moving a file to svm/ (and subsequently simplifying the file to just the needed parts) is only used for situations where the diff to the OpenJDK is so large that complex merge conflicts would be pretty much guaranteed when updating.

Regarding 5:
Yes, pretty much all code that is supposed to end up in the native GC library should be in the svm_gc namespace to avoid naming conflicts. The pattern #ifndef SVM namespace svm_gc { should only appear in files that contain types whose layout needs to be visible on the Java-side of SVM (the image build generates C code to determine the offsets of fields and the sizes of types).

[simonis]

@christianhaeubl, why have you set ClassUnloading to trueInSvm and ClassUnloadingWithConcurrentMark below to falseInSvm? I thought there is currently no runtime class loading/unloading in SubstrateVM, so shouldn't ClassUnloading be falseInSvm as well?

[christianhaeubl]

I initially enabled that option because HotSpot’s code unloading logic is more aligned with what Native Image needs when class unloading is active. However, this doesn't seem to be relevant anymore (the code unloading logic is now a custom SVM-specific implementation), so we can and probably should set both ClassUnloading and ClassUnloadingWithConcurrentMark to falseInSvm.