Agent and sizing

[Remi Forax]

----- Mail original -----
> De: "Henri Tremblay" <henri.tremblay at gmail.com>
> À: "Stephen Felts" <stephen.felts at oracle.com>
> Cc: "jdk9-dev" <jdk9-dev at openjdk.java.net>
> Envoyé: Vendredi 13 Octobre 2017 16:13:49
> Objet: Re: Agent and sizing

> 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?

Yes and No.

1) as a user you can open your module (or better your package inside a module) if you want deep reflection to be performed by a tool
2) if you are using a container, it will use a ModuleLayer so it can open the package/module for you
3) if you use an agent, the agent will open the package/module for you.

so there problem is if you try to do deep reflection on the JDK, i will fail, but this is what we want so we can refactor the JDK, something we can hardly do before 9, or if you try to do deep reflection on a module which is not open but this is what we want by design of the module system.

cheers,
Rémi 

> 
> 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
>>
>>