JDK-6439227 : can_generate_all_class_hook_events and sharing may need a tweak
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-06-15
  • Updated: 2023-12-13
  • Resolved: 2016-11-04
Related Reports
Relates :  
Relates :  
Relates :  
Description
In the current system (as of Mustang-B89), if the can_generate_all_class_hook_events
capability is acquired in the OnLoad phase, then sharing is disabled. If sharing is
not enabled then the can_generate_all_class_hook_events capability can be acquired
in any phase. If sharing is enabled, then the can_generate_all_class_hook_events
capability cannot be acquired after the OnLoad phase.

During discussions about 5002268, 6431456 and 4956521, changing the relationship
between can_generate_all_class_hook_events and sharing was also discussed. A couple
of possibilities emerged:

1) If can_generate_all_class_hook_events is acquired in the OnLoad phase,
   then don't disable sharing. Instead remap the shared readonly space to
   shared readwrite, private (see 5002268) and post CFLH events for all
   shared classes.

2) Keep the logic that disables sharing if can_generate_all_class_hook_events
   is acquired in the OnLoad phase. Allow can_generate_all_class_hook_events
   to be acquired in any phase. If can_generate_all_class_hook_events is
   acquired after the OnLoad phase, then CFLH events don't need to be posted
   for the shared classes in any case since the classes were "loaded" before
   the capability was acquired.

Option 2 is much simpler so that option is looking best at the moment.

Comments
This is not on our list of current priorities. If this changes, please reopen this issue.
04-11-2016

Additional comment from David H. (to the comment from Staffan): You can also read "Some classes might not be compatible with the function (eg. ROMized classes) and this event will not be generated for these classes." as only being applicable in the primordial phase - while shared classes are also loaded during other phases. David
25-11-2014

This is a suggestion from Staffan L. to update the RetransformClasses() spec as well: > It is already documented in the JVMTI spec: > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#ClassFileLoadHook > > The spec tells: > "This event may be sent before the VM is initialized (the primordial phase). During this time no VM resources should be created. Some classes might not be compatible with the function (eg. ROMized classes) and this event will not be generated for these classes. " > > The spec also tells this: > > Capabilities > Required Functionality > Optional Features > Capability Effect > can_generate_all_class_hook_events Can generate ClassFileLoadHook events for every loaded class. > > > > The question is if it is good enough. Perhaps we should add a note saying that can_generate_all_class_hook_events is not needed for retransform to work. It’s only needed if the agent expects ClassLoadHook events for all classes when they are loaded “normally”. Also there is nothing connecting the note about ROMized classes above and the can_generate_all_class_hook_events capability. Perhaps those two statements should be linked somehow. /Staffan
25-11-2014

This issue looks like Enhancement, changing ... Also wanted to add this link to simplify the reading of bug description: http://bugs.java.com/view_bug.do?bug_id=5002268
25-11-2014