Hi Jiangli,
Thanks for your quick reply, your concerns are very reasonable. Let me clarify them one by one.
1. Goal
Alignment of goals is important. Our goal is to make Java applications start faster as possible as they could, actually that's what the project name(jdk11u-fast-startup-incubator) means. Based on this goal, any specific techniques such as CDS-based heap archiving and AOT are welcome, it seems that we are both interested in CDS-based heap archive.
2. Milestones and Roadmap
I suggest following the upstream release cycle, i.e. release a new build every 3 months. In the single release cycle, we can set up some feasible milestones. For example, the first milestone could be: Backport preliminary patches from upstream and prepare an initial patch(http://cr.openjdk.java.net/~jiangli/Leyden/general_class_pre_initialization_core_mechanism/general_class_pre_init_patch_1.) for later development.
3. Code review and feature/bug tracking
I find neither any bug tracking systems nor find code review and commit rules in eclipse foundation(Please let me know if it indeed exists), so I propose using the following format(which is similar to JDK PR format):
#GITHUB-ISSUE-ID: Title of patch
e.g.
#377: Backport some stuff...
Just IMHO, any other formats are welcome.
4. Technical details
> Agreed. I've backported that in our JDK 11 codebase. We can backport that for the JDK 11 based collab repo.
I'd like to backport JDK-8206009 to our collaboration repo as my first patch. Thank you for comparing and listing some preliminary patches in https://github.com/jianglizhou/adoptium-startup-incubator-docs/wiki/Backports-Needed-for-General-Java-Class-Pre-initialization-Work. Later, I will file an Github issue that has corresponding name with JBS issue name to mark a backport-patch is working in progress.
> For #1, #2 and $4, those are addressed (or partially addressed) by http://cr.openjdk.java.net/~jiangli/Leyden/general_class_pre_initialization_core_mechanism/general_class_pre_init_patch_1. It implements my Java Class Pre-resolution, and Pre-initialization design proposal. Is everyone okay with taking our patch and collaborating on top of it? We can follow a review process that's agreed for the collab repo.
Very great! Taking that patch as an initial patch could drive further development.
> OpenJDK has some work done in that area. We can evaluate the benefits and explore.
> That sounds like a longer term goal and has the dependency on actual usages of ShenandoahGC/ZGC.
Yes, they are just brain storm. In my internal practice, I don't implement partial pre-initialization, I find most time-consuming classes contain at least one lambda field in its subgraph. But with your patch, it's possible to pre-initialize partial class, so this might not so important.
Thanks,
Yang