Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [adoptium.incubator-dev] 回复： Some ideas about pre-initialization
Hi Sanhong,

On Wed, Apr 28, 2021 at 6:17 AM 李三红(三红) <sanhong.lsh@xxxxxxxxxxxxxxx> wrote:
Hi Jiangli,
Thanks for good suggestions!  
I fully agree we need a broader project goal,  we can consider documenting our goal in the README file [1]. 

Sounds good and it would be good to define the project goal/mission coordinately together.  
 
For milestones/roadmap, my initial thought is we can have the same cadence with OpenJDK11u,  e.g. set the expected deliverables per quarterly release.

It might be better to consider defining the milestones in terms of ripe proposals (possibly involving JEPs) in OpenJDK, without making releases.  That inlines better with the intent of Eclipse Adoptium Incubator:

"The intent of the proposed Eclipse Adoptium Incubator is to foster collaboration, and hopefully results in work proceeding to contribution by their original authors into upstream projects, including OpenJDK, or moving the work into a new Eclipse Adoptium project. The Adoptium Incubator would not make any releases itself."

For the pre-initialization work itself, how about the following milestones?
  • General support for pre-initializing JDK classes 
  • Pre-initialization for application classes with the static analyzer for safe-guard (could be broken into two separate milestones)
For bug tracking/code review,  how do you think we can just re-use the PR system in GitHub - actually we are doing it the same way in Eclipse/Jifa project [2].

That sounds good. 


Best,
Jiangli
 

Thanks!
Sanhong
------------------------------------------------------------------
发件人：Jiangli Zhou <jianglizhou@xxxxxxxxxx>
发送时间：2021年4月28日(星期三) 10:27
收件人：杨易(青风) <qingfeng.yy@xxxxxxxxxxxxxxx>; adoptium.incubator developer discussions <adoptium.incubator-dev@xxxxxxxxxxx>
主　题：Re: [adoptium.incubator-dev] Some ideas about pre-initialization

Hi, 

On Sun, Apr 25, 2021 at 6:36 PM Jiangli Zhou <jianglizhou@xxxxxxxxxx> wrote:
Hi Yi Yang and everyone,

Thanks a lot for creating the incubator project and initiating the discussions (catching up after some slowdown on my side for a couple of days from last week)! Truly excited about the collaboration and the potential it may achieve. A few high level thoughts before diving deep into the technical discussions.

Goal
The startup incubator project has similar traits (or subset of those) as the OpenJDK Leyden project, which targets for producing a static image for optimized startup time, slow-to-peak performance and runtime memory footprint. The static image may include pre-generated class metadata, Java heap objects and compiled code. It would be good to have that broader goal in mind when we collaborate. Our JDK 11 based collaboration here may help innovations in OpenJDK head and fuel inspirations for Leyden.

Milestones and Roadmap
You brought up the question about future roadmap. It would be good to identify the achievable milestones. Based on our previous discussions, we both are interested in improving OpenJDK CDS (Class Data Sharing) based heap archiving for more general class pre-initialization as a short-term milestone. Based on my past experiences from AOT work on JavaME CVM, pre-resolving constant pool references (pre-initialization assists pre-resolving) help generate more optimal ahead-of-time compiled code. Are there other ideas that we can explore beyond those? It's a good idea to document the milestones and roadmap in https://github.com/adoptium/jdk11u-fast-startup-incubator/wiki.

Code review and feature/bug tracking
Which bug system can be used to help track features and bugs for our JDK 11 based collaboration here? Are there established Eclipse Foundation code review and commit rules that we can follow when collaborating using the jdk11u-fast-startup-incubator repository?

Please see more comments inlined below. 

On Thu, Apr 22, 2021 at 3:50 AM Yi Yang <qingfeng.yy@xxxxxxxxxxxxxxx> wrote:
Hi all,

There I have some ideas about pre-initialization:

1. Backports

As discussed with @jiangli before,
> The current general class pre-initialization work is based on JDK 11 with some backports from OpenJDK 12 & 13, particularly with the backport for https://bugs.openjdk.java.net/browse/JDK-8206009. Majority of the needed backports have already landed in OpenJDK 11. We still need to backport JDK-8206009 to jdk11u-dev-class-preprocessing.
This seems to be a good starting point, I can try to backport it. 

Yes, the majority of the needed backports have already landed in OpenJDK 11.
 
Besides, do you think there is any prerequisite patch that we must backport right now? 

I'll run a full comparison against OpenJDK 11 and send out the list of needed additional backports tomorrow or the day after tomorrow.


Best,
Jiangli
 
 
If not, we can consider developing new features until we need to backport some patches in later development.

2. New features
1) Allow pre-initializing fields whose types are primitives
2) Remove hard-coded archivable_static_fields, accepts users inputs, either a safe fields/klass list or fields/klass that annotated with @Preserve or whatever you like
3) In HeapShared::initialize_from_archived_subgraph, find the klass in hashmap instead of an array, this had been done in upstream

Agreed. I've backported that in our JDK 11 codebase. We can backport that for the JDK 11 based collab repo.
 
4) Safety check. Checking if given input is valid

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.

There are additional bug fixes and enhancements on top of that.
 
5) Allow pre-initializing lambda fields

OpenJDK has some work done in that area. We can evaluate the benefits and explore.
 
6) More region-based GC supports(ShenandoahGC/ZGC)

That sounds like a longer term goal and has the dependency on actual usages of ShenandoahGC/ZGC. 
 

IMHO, I prefer item 2) since other items require removing hard-wired code and accepting users' input as their preconditions.

Agreed.

Your static analyzer proposal for checking the 'safty' of pre-initialization was interesting to us. Could you provide a timeline for that?

Best,
Jiangli


Do you have any ideas about the future roadmap? I'm new to pre-initialization, anything that is not listed above can also be raised. I'm very glad to hear about your ideas/feedback, any input is appreciated!

Best Regards,
Yang
_______________________________________________
adoptium.incubator-dev mailing list
adoptium.incubator-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

_______________________________________________
adoptium.incubator-dev mailing list
adoptium.incubator-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

Back to the top