Call for Discussion: New Project: Leyden

[Jiangli Zhou]

Hi Esteban,

Thank you for the feedback! Very happy to see the involvement from you
and others from GraalVM (based on Mark's CFV email)!

Freeing developers from having to do any manual configuration (or
having to write any scripts to semi-automate the configuration) in
order to use the image during deployment would be very important. The
adoption of a static image solution will likely be higher when that
barrier is gone. Developers may be more willing to do source level
change in the following case:

- anticipated benefit is clear
- easy to use/no manual configuration

Would it be possible to do an incremental and divide & conquer
approach? JDK library, app library, and application developers/experts
may add the 'marker' in their own domain, and the savings would be
higher with more Java code adopting this new feature.

Another possible approach is using the 'marker' solution together with
static analysis (brought up by another member during an internal
discussion). It may be possible to provide two different usage modes,
power mode and marker-only mode. If static analysis can sufficiently
tell us which are the good candidates for pre-initialization at build
time, we can pre-initialize more classes without relying on the
'marker'. That would be a 'power' mode. Static analysis does cost CPU
cycles at build time and may require more memory. In many cases,
developers may opt-in for the 'marker-only' mode to avoid higher
CPU/memory cost at build time, when sufficient Java sources are marked
for class pre-initialization...

Looking forward to seeing more inputs/advice.

Best,

Jiangli


On Mon, Jun 8, 2020 at 10:00 AM Esteban Ginez <esteban.ginez at oracle.com> wrote:
>
> 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> wrote:
>
> 2020/5/18 15:43:34 -0700, 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:
>
> Design doc:
> 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
>
> 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
>
>