RFR JDK-8232222: Set state to 'linked' when an archived class is restored at runtime

Jiangli Zhou jianglizhou at google.com
Wed Jun 3 19:29:49 UTC 2020

On Wed, Jun 3, 2020 at 11:48 AM Ioi Lam <ioi.lam at oracle.com> wrote:
> Hi Jiangli,
> My point is, if we are introducing a behavioral change in an
> optimization, it should be carefully reviewed. That's a rule we have
> followed all along.

Totally in agreement. It's another reason why David's suggestion of
creating the CSR is a great idea.

Please see my analysis about boot class loading in the previous email.

> Can we first push your change without the JVMTI behavioral change, and
> discuss the JVMTI behavioral change separately?

I've waited for half-year already, I can wait for a few more days.
Let's get this class_prepare event sorted out first, so we set the
right tone for future optimizations.

> If I understand your proposal correctly, in this RFE, we will first set
> boot classes to "linked" during restore_unsharable_info(). Subsequently,
> we will do the same thing for other classes. And after that, we will set
> classes to 'initialized' during restore_unsharable_info().

That's what I think would be the right thing to do, and plan to do so.
Let's focus on the 'linked' state for the archived boot classes in the
current scope, otherwise we will not be able to make any meaningful

> If that's the proposal, then we will be introducing more and more
> behavioral changes that are not only observable by JVMTI but also by
> Java code. I think we should discuss all these together to see if this
> is indeed the direction we want to take. Project Leyden is the right forum.

Sorry that I'm reiterating myself, the class-preinitization should be
discussed as part of the Leyden. The 'linked' state for the archived
boot classes can be discussed and moved forward now.


> Thanks
> - Ioi
> On 6/3/20 9:34 AM, Jiangli Zhou wrote:
> > Hi Ioi,
> >
> > Monitoring agents are alway enabled in cloud production environments.
> > The costs for agents are constant and always exist. The main
> > motivation for the CDS work during the last several years was for
> > cloud environments. Could you please explain why you think CDS should
> > not be used for startup saving with JVMTI agents in cloud? Or, this
> > and related future optimizations should not be enabled in that case?
> >
> > Majority of the Java startup improvement since OpenJDK 9 was achieved
> > by small incremental improvements. Each such change has been a small
> > saving only. Some of them were small enough and only measurable by
> > instruction counts. However they were all worth the work and have been
> > submitted to OpenJDK. As a result, we are seeing a good total startup
> > improvement today with CDS enabled.
> >
> > This change is no exception. Even the saving is small, but it still
> > should be done. Although I don't have data with agent enabled, I have
> > provided performance data for before and after the change since the
> > very beginning. In addition, I have also explained a few times that
> > this change enables future optimizations for more general class
> > pre-initialization approach. This is an important step for future
> > work. So doing it right is crucial.
> >
> > Regards,
> > Jiangli
> >
> > On Tue, Jun 2, 2020 at 9:34 PM Ioi Lam <ioi.lam at oracle.com> wrote:
> >> Hi Jiangli,
> >>
> >> Before we spend time on the CSR review, do you have any data that shows
> >> the actual benefit of doing this? I am specifically asking about the
> >> benefit to JVMTI agents.
> >>
> >> As I mentioned before, there's an alternative, which is to not use the
> >> optimization when JVMTI is enabled. I don't think we should spend time
> >> worrying about the impact to JVMTI agents unless there's a compelling
> >> reasons to do so.
> >>
> >> Thanks
> >> - Ioi
> >>
> >>
> >>
> >> On 6/2/20 5:19 PM, Jiangli Zhou wrote:
> >>> Here is the CSR: https://bugs.openjdk.java.net/browse/JDK-8246289.
> >>>
> >>> David, I described that the JVM spec allows for eager or lazy linking
> >>> and agents shouldn't rely on the timing/ordering, as you suggested.
> >>> Please review the CSR. It's been a while since I've worked on a CSR,
> >>> could you please remind me if the CSR should be proposed before
> >>> reviewing? I can revert it to draft state if draft is the correct
> >>> state before reviewing. Thanks!
> >>>
> >>> Best regards,
> >>> Jiangli
> >>>

More information about the hotspot-runtime-dev mailing list