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