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

[Ioi Lam]

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.

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

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().

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.

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
>>>