> On Apr 2, 2016, at 2:53 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > (cc'ing serviceability-dev as this is where this code is maintained). > > >> On 02/04/2016 00:32, Mandy Chung wrote: >> Hi Chris, >> >> Would jdk.internal.vm be appropriate for this VMSupoprt class? > I agree. > >> >> VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. >> java.management could call JVM_InitAgentProperties directly. >> >> src/jdk.jdwp.agent/share/native/libjdwp/util.c >> JDWP calls it and needs to be updated. > If I recall correctly then this is so that the debugger transport details can > be advertised. There is a process AttachingConnector that depends on that so > I agree this needs to be updated. > >> >> VMSupport.getVMTemporaryDirectory() is for jdk.jvmstat to use and I suggest >> to move this method to jdk.internal.perf.Perf. > It could although I assume this means that introducing a new shared library.
jdk.internal.perf is in java.base. Another option is to move it to jdk.jvmstat that i considered but may not worth it since perf counter is still in java.base. Mandy > >> >> Mandy >> >>> On Mar 31, 2016, at 9:02 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >>> >>> As part of JEP 260, all non-Critical APIs in sun.misc are being examined. >>> >>> sun.misc.VMSupport is a utility class supporting two functions: >>> 1) the initialization of management Agent properties, and >>> 2) the retrieval of the VM temporary directory used by the attach and perf >>> data files. >>> >>> The initialization of Agent properties is used statically by the >>> java.managment module, >>> or can be provoked by a serviceability tool on a VM that has had an agent >>> loaded in it. >>> The location of VM temporary files is a low-level interface between the >>> libraries and VM. >>> For these reasons, VMSupport should remain in the base module, but be moved >>> to an >>> internal package. >>> >>> http://cr.openjdk.java.net/~chegar/8153181/00/ >>> https://bugs.openjdk.java.net/browse/JDK-8153181 >>> >>> -Chris. >
