Agent and sizing

Sun Oct 15 04:13:29 UTC 2017

Hum.... I think there is a big focus on using internal implementations that
prevents refactoring. It think people using internal implementations are
grown-ups. They can deal with it.

I am a bit after the fact here but I will still say it:

Objenesis is creating objects using JDK internal implementations. Since
Java 1.3 it broke multiple times and I've fixed it without complaining.
Because I'm using stuff that can change. It's my problem

The only thing I'm complaining about for years is that there should be a
public API for what Objenesis is doing. Because it's doing something useful
(which means: Used by probably 95% of the applications currently in
production). So something like Unsafe.allocateInstance should be public
API. Because we need it. That is just basic pragmatism.

Crawling through objects to discover their size is also a legitimate use
case. There's nothing wrong there and I'm not relying at all on internal
implementations. Even more: I'm resilient to them. If String internal
implementation switch for char to byte array, it still works. Nothing
should prevent me from doing it.

Remi, thanks for your answer. According to it, it seems impossible to open
the JDK apart from using JVM parameters. Even an agent can't. Am I right?

If yes, it is a terrible thing. In my head, as soon as you are doing
reflection on another package, including the JDK, you are on your own.
Things can break. That's my problem. New synthetic methods can appear,
things can move around, etc, etc. So, for static code, I'm all in for
restricting access. For dynamic code, no, all modules should be open by
default.

That's what will happen anyway.

If you are a module and want to allow legitimate reflection, you should
open everything or you will be unusable.

Henri

On 13 October 2017 at 12:44, Remi Forax <forax at univ-mlv.fr> wrote:

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