Agent and sizing

[Henri Tremblay]

I think we have a problem here. It means heap walking is not allowed in
Java 9. Without passing special JVM parameters.

This seems quite limitative for frameworks doing proxying, annotation
discovery on classes from unknown places.

No?

On 13 October 2017 at 00:05, Stephen Felts <stephen.felts at oracle.com> wrote:

> The short answer is no.
>
> There isn't any programmatic way to know in advance if a warning will be
> printed. It's easy to test if packages are open to only all unnamed modules
> but this isn't enough - the reason is that packages can be opened
> explicitly, via --add-opens`, and there won't be warnings there is an
> otherwise illegal access to a member of the packages opened this way.
>
>
>
> With the current default of --illegal-access=warn, a single warning will
> be printed.  You can catch the exception and ignore it so the code will be
> quiet when the default changes to --illegal-access=deny.
>
>
>
>
>
> *From:* Henri Tremblay [mailto:henri.tremblay at gmail.com]
> *Sent:* Thursday, October 12, 2017 11:54 PM
> *To:* Stephen Felts <stephen.felts at oracle.com>
> *Cc:* jdk9-dev <jdk9-dev at openjdk.java.net>
> *Subject:* Re: Agent and sizing
>
>
>
> Thanks a lot to you both! That helps a lot.
>
>
>
> And so, for the other question: Is there a way to walk through fields on
> classes the can be anywhere without tons of warnings?
>
>
>
> On 12 October 2017 at 15:55, Stephen Felts <stephen.felts at oracle.com>
> wrote:
>
> One way is to set the environment variable JDK_JAVA_OPTIONS="-Djdk.attach.allowAttachSelf=true"
> to turn off the self-attach error.
>
> Another way is to use ProcessBuilder to create another process and have
> the new process attach.  This follows all of the current rules.  Several
> projects are using this approach.
>
> -----Original Message-----
> From: Henri Tremblay [mailto:henri.tremblay at gmail.com]
> Sent: Thursday, October 12, 2017 3:35 PM
> To: jdk9-dev <jdk9-dev at openjdk.java.net>
> Subject: Agent and sizing
>
> 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
>
>
>