Attaching to a JVM image that does not include java.instrument

[Rafael Winterhalter]

I do not think that people would normally try to dictate it but there is a
good chance that people follow the default setting and ignore the warning
message. I rarely see a build without warnings, people normally look away.

The problem I see is that the people in charge of building and packaging
the application do not necessarily understand the purpose of JVMTI with
regards to tooling. If such an image is distributed, this has an impact on
the users of the image which often require agents to monitor their
environments. Basically any customer of mine that I have worked with in the
last 5 years is using such agent-based monitoring.

To overcome this limitation, a production team could of course ask the team
that is maintaining the image to add the module and release an updated
version, but by my experience, such coordination is difficult and expensive
no matter how trivial it sounds. It is a great feature of such tooling to
"just work" which is now mitigated.

Personally, I fear that this could introduce some form of cluttering in the
Java market. Few people understand JVMTI or even know about it. To those
people, it would just seem like this tooling only sometimes works with Java
processes, making the platform appear less reliable. And for maintainers of
such tooling, there is no way around other than patching the image prior to
attachment (what is possible by copying some files around, but it feels
like a hack).

JVMTI has become an essential feature of the JVM for a reason. I still hope
it would be a part of any jlink image for the sake of consistancy and
reliability.


2017-05-22 12:49 GMT+02:00 Andrew Dinn <adinn at redhat.com>:

> Hi Volker,
>
> On 19/05/17 19:39, Volker Simonis wrote:
>  <snip>
> > So why did I wrote all that? I think I just wanted to emphasize the
> > following points:
> >
> >  - We need good/better standards (and that's why the JCP is so
> important)!
> >  - With great power comes great responsibility (i.e. as a
> > Java/application provider, use JPMS/jlink wisely)!
> >  - As a Java user, insist on getting a "full" JDK (i.e. one which
> > contains the java.se/java.se.ee module)!
>
> I agree with all these recommendations. However, I want to just comment
> on the second one, specifically wrt jlink.
>
> What constitutes a /wise/ use of jlink really depends on the purpose of
> the jlinked image. I can envisage many cases where a custom jlinked
> image without instrumentation capabilities might look attractive as a
> way to save on memory footprint (not just the java classes but also the
> code needed in libjvm.so). Footprint is a significant issue for certain
> classes of application.
>
> The sort of case I envision where this concern would be legitimate would
> be, say, a shrink-wrapped Java utility program that does a very specific
> and, probably, quite short-lived job; one that has been well tested and
> validated, first in a sandbox and then in the field.
>
> A more general purpose image, in particular one that is likely to run an
> app that installs runtime defined deployments that are not linked in the
> base image -- even if that is only a small amount of code -- may well
> run up against problems that only an agent can help diagnose and remedy.
> So, I can't see it being a wise idea to omit agent support in such images.
>
> Lastly, I'll add that I don't believe agent developers have any right to
> /dictate/ to users of jlink what they should or should not do. The onus
> is for us to make them aware of what they might be missing by ruling out
> use of our tools and make those tools so compelling that they recognise
> and agree that the benefits are worth preserving. As long as the option
> to include or exclude agent support is available, then to me it's simply
> a free and open market, trading quality and reliability at the potential
> cost of footprint. I'm very happy to compete on those terms.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>