On Mon, 8 Aug 2022 01:26:11 GMT, David Holmes <dhol...@openjdk.org> wrote:
> My issue with these kinds of changes in general is that they: > > * undermine institutional memory > * make it harder to do backports due to the shuffling > * make it harder to track changes due to the shuffling > > So the benefit to me has to be more than just a small decrease in some build > times which most people are never going to notice anyway. Sorry. Just my 2c. While I understand the concerns, the above reason can be used against any sort of refactoring of the source code. We have a few decades of development, resulting slow but steady source code rot. We need to refactor the code when it makes sense to keep the repo healthy. Yes, the above are valid concerns, but we have been successful in dealing with them in past refactoring exercises. Build time is important for HotSpot developers. I figure that the header file refactoring that happened in the last year or so (by myself and others) have resulted in 20% or so reduction in build time. So of that was taken back, though, due to new features such as Loom. I tried to limit the amount of code to be moved. However, when a file like javaClasses.hpp grows to over 2000 lines or mostly unrelated declarations, it's a sign that it needs to be broken up (which I started doing since JDK-8288623). ------------- PR: https://git.openjdk.org/jdk/pull/9788
