Hi -
I think the history of post_vm_init_hook_enabled was from the
hotspot-express idea that the JVM and the runtime environment could be
separate. We could release a new JVM and slot it into an existing
JDK/JRE... In practice, the commented future optimisation never
happened, but they've been in unison for years now and the VM has always
tried to run PostVMInitHook, specifically ignoring any problems such as
the class not existing in an open build.
Duplication inside PostVMInitHook.java was to avoid loading additional
classes in every JVM everywhere unless they were likely to have the
logger configured.
(I've seen Sharath's deferral message, but thought I'd mention this
historical point...)
Thanks!
Kevin
On 31/05/2018 03:44, David Holmes wrote:
Hi Sharath,
I second Bernd's comments about removing all the ORCL_ prefixes.
I'm unclear how this utility is managed. I expect it to be opt-in but
I see:
// Advertise presence of PostVMInitHook:
// future optimization: detect if this is enabled.
info->post_vm_init_hook_enabled = 1;
in src/java.base/share/native/libjava/jdk_util.c, which suggests it is
in fact always going to be run (at least to the point where it looks
for the config file).
Thanks,
David
On 31/05/2018 1:50 AM, Sharath Ballal wrote:
Hello,
Requesting reviews for Usage Logger open sourcing (earlier known as
Usage Tracker).
ID: https://bugs.openjdk.java.net/browse/JDK-8199729
Webrev: http://cr.openjdk.java.net/~sballal/8199729/webrev.00/
Mach5 run has been successful for Usage Logger tests and hs-tier1,
hs-tier2.
Thanks,
Sharath
