Call for Discussion: New Project: Leyden

[Esteban Ginez]

Hi Jiangli

I took some time to review some of the docs you sent about class initialization, and I would like to highlight one key thing we have been observing in the Graalvm team.

The usage of annotations to mark classes as ’pre-initializable’ is insufficient.
The  java community relies on well known, time tested,  java libraries. It is often the case that the application owner relies on dependencies he does not even know (or care to know) about . Restricting the capacity to pre-initialize an application via annotations, at minimum, will leave behind code that can not be annotated due to lack of ownership. Further, as we have been experiencing in the GraalVM team, it has been challenge for lower level libraries, to a-priory decide the set of code that can be pre-initialized, without taking into consideration the particular usage of the library.

That being said, it is great to see other teams in the community working on similar problems, so thanks a lot of sharing your work
Warmly
E. 

> On May 21, 2020, at 5:23 PM, Jiangli Zhou <jianglizhou at google.com> wrote:
> 
> On Thu, May 21, 2020 at 3:48 PM <mark.reinhold at oracle.com <mailto:mark.reinhold at oracle.com>> wrote:
> 
>> 2020/5/18 15:43:34 -0700, jianglizhou at google.com <mailto:jianglizhou at google.com>:
>>> Didn't see this discussion until today. I think this will be welcomed by
>>> Java developers! How do we participate in the project and coordinate?
>> 
>> I’ll shortly start the CFV to create the Project.  Once the Project
>> exists, your participation will be most welcome!
>> 
> 
> Sounds great!
> 
> 
>> 
>>> I have been experimenting with preserving pre-initialized classes (at
>> build
>>> time) as part of the CDS archive image. Class pre-initialization can help
>>> field and method pre-resolution and generate better AOT code. Here is a
>> class
>>> pre-resolution & pre-initialization proposal
>>> <
>> https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing
>>> 
>>> that enhances
>>> the existing Hotspot heap archiving and provides more general support to
>>> pre-initialize classes and preserve static field values for both JDK
>>> classes and application classes (loaded by system class loader).
>> 
>> Sorry, but for IP clarity could you please either post that document to
>> cr.openjdk.java.net or enter it into a JBS issue?  (Likewise for the
>> slides that you mention later on.)
>> 
> 
> I've posted the docs to cr.openjdk.java.net <http://cr.openjdk.java.net/>:
> 
> Design doc:
> http://cr.openjdk.java.net/~jiangli/Leyden/Java%20Class%20Pre-resolution%20and%20Pre-initialization%20(OpenJDK).pdf <http://cr.openjdk.java.net/~jiangli/Leyden/Java%20Class%20Pre-resolution%20and%20Pre-initialization%20(OpenJDK).pdf>
> Slides:
> http://cr.openjdk.java.net/~jiangli/Leyden/Selectively%20Pre-initializing%20and%20Preserving%20Java%20Classes%20(OpenJDK).pdf <http://cr.openjdk.java.net/~jiangli/Leyden/Selectively%20Pre-initializing%20and%20Preserving%20Java%20Classes%20(OpenJDK).pdf>
> 
> Will also attach them to JBS as suggested.
> 
> 
>>>                                                                 I
>> adopted
>>> the annotation approach in the proposal, after comparing it to other
>>> alternatives, please see details in the design doc.
>> 
>> In a prototype, using an annotation to identify pre-initializable
>> classes is fine.  In the long run, however, we’ll likely wind up with a
>> keyword since annotations must not be used to change language semantics.
>> 
> 
> That sounds workable. The underlying heap object archiving mechanism can
> support different approaches (list, interface, annotation, keyword, etc) as
> an 'indicator' for pre-initializing & preserving classes and static fields.
> 
> Really excited about the project!
> 
> Best regards,
> Jiangli
> 
> 
>> - Mark