Agent and sizing

Michael Rasmussen michael.rasmussen at zeroturnaround.com
Thu Oct 12 19:53:13 UTC 2017


As of Java 9, the attach API isn't allowed to attach to itself anymore.

To circumvent it, you can for instance look at what Byte Buddy does, or
simply depend on byte-buddy-agent to get an instance of Instrumentation by
doing inst = ByteBuddyAgent.install();
For the code, see
https://github.com/raphw/byte-buddy/tree/master/byte-buddy-agent

/Michael



On 12 October 2017 at 22:35, Henri Tremblay <henri.tremblay at gmail.com>
wrote:

> Hi,
>
> Yesterday I was playing with the sizeof <https://github.com/ehcache/sizeof
> >
> library on Java 9. I was expecting bad things to happen. And I was right.
>
> The purpose of this library is the give on heap occupation. We use it for
> ehcache to know the size of the on heap cache and it is used by some other
> frameworks as well.
>
> I noticed two things. First, we load dynamically an agent in the current
> JVM. This is done by reflection so it will be something like:
>
> Class vm = Class.forName("com.sun.tools.attach.VirtualMachine");
>
> Method attach = vm.getMethod("attach");
>
> String name = ManagementFactory.getRuntimeMXBean().getName();
>
> attach.invoke(null, name.substring(0, name.substring(0,
> name.indexof('@')));
>
> It works fine on Java 8 but fails on Java 9 with IOException: Can not
> attach to current VM.
>
> *How can I fix it?* (we then use the Instrumentation to do a getObjectSize.
> It is one of the ways to make it work).
>
> My other question is about the other sizeof implementations. One is using
> reflection to go deep into objects until reaching the primitives. That will
> make the JVM scream warnings all over the place I think.
>
> Another is using Unsafe (objectFieldOffset, arrayBaseOffset,
> arrayIndexScale) to calculate the size. I think this one should not cause
> too much warnings.
>
> *So, I guess there is not much I can do for the ReflectionSizeOf appart
> from adding tons of JVM params?*
>
> Thanks a lot,
> Henri
>


More information about the jdk9-dev mailing list