On 2 December 2015 at 15:31, Alan Bateman <alan.bate...@oracle.com> wrote: > "JVM TI agents can no longer instrument Java code that runs early in the > startup of the run-time environment. The vm start event is not sent until > the module system is initialized, so JVM TI agents that do load-time > instrumentation will not receive ClassFileLoadHook events for classes > loaded during startup and they will also miss some previously-received > CompiledMethodLoad and DynamicCodeGenerated events. Agents can use the > GetLoadedClasses function to get the list of loaded classes and the > GenerateEvents function to generate missed events. (Java agents will > continue to function as before, since they run only during the live phase.)" > > So you won't see CFLH events until the Start phase. > > I think this can be re-visited once there is support for "module aware" > agents. The important thing that agents will not be able to load classes > outside the java.base module until the module system has been initialized.
Well, you've always had to be very careful loading classes before VMInit, you had to be really careful not to use things that wasn't initialized yet. I don't see why it was felt neccesary to completely block the CFLM events for these classes, making it hard to fully instrument the bootstrap classes without having to do it in two passes, and supplying -Xpatch. Also, last I checked, when java.base is defined in the VM, it's verified that only packages from java.base has been defined so far, and if not it is a fatal error; so even if someone tried to load a class outside of java.base, that verification would kick in, and the VM would halt. "Agents can use GetLoadedClasses function to generate the missed events" doesn't really solve the problem. Yes, you can retransform the classes afterwards, but that limits you to only change method bodies, thus cannot add members to the classes. > Just on steps to update these APIs for modules then we should have an > initial patch soon to help debugger agents. This has wider scope because > it requires updates to JVM TI, JDWP and JDI. We need to work on > instrumentation support too so use-cases, examples, and working with us > to get this right would be great. Considering you also recently removed the system property "sun.boot.class .path" (which is now live in the b94 build that just became available for download), it would be very appreciated if an option were added back to the JVM TI, so we have some way of either telling the VM to use this patch dir/jar/jimage, and also be able to get CFLH events for classes being loaded during primordial phase as well. /Michael
