RFR - Changes to address CCC 8014135: Support for statically linked agents

[Jeremy Manson]

Okay, Bob, thanks for the explanation.  I may not agree with it, but I can
certainly see where you're coming from.

Jeremy


On Tue, Jul 16, 2013 at 2:44 PM, Bob Vandette <bob.vandette at oracle.com>wrote:

> Thanks for the suggestion Jeremy but the JVMTI agent change is being
> implemented as part of the
> original JNI static library implementation where we explicitly prohibited
> dynamic libraries to be loaded
> if a static library of the same name is baked into the launcher.
>
> "If a library L is statically linked then it will be prohibited to link a
> library of the same name dynamically."
>
> The primary motivation for requiring this for the -agentpath as well as
> the java.lang.System.load API is to
> minimize changes to java source code.  You can statically or dynamically
> link a library without changing
> any of the code that attempts to use the library.  The only thing that
> changes is the OnLoad name in the library
> and the link options.
>
> If you'd like to optionally use different implementations, you can end up
> with the same behavior by using a
> System property which alters the String of the name of the library.
>
> Bob.
>
>
> On Jul 10, 2013, at 3:29 PM, BILL PITTORE wrote:
>
> On 7/3/2013 6:32 PM, Jeremy Manson wrote:
>
> I know that this is mentioned in the JEP, but does it really make sense to
> have -agentpath work here, rather than just -agentlib?  I would think that
> specifying a full pathname and getting the library loaded out of the
> launcher would be a little surprising to people who are basically saying
> "please load this agent from the given path".
>
>
> Also, in practice, we do something very similar at Google, and, when
> testing, I find it occasionally useful to be able to say "please load this
> agent on the command line via the agentpath I gave you, rather than loading
> the one with the same name I baked into the launcher".
>
>
> (FWIW, when we did this internally at Google, we added a special -XX flag
> for when the agent is in the launcher.  I know that you don't want to go
> that way, though.)
>
>
> Thanks for the comments.  I would say the thinking here is that we want
> this to be as transparent as possible to the end user. In our view of the
> end user is someone perhaps using an IDE and the actual execution of the VM
> with agent arguments is hidden. In your case it sounds like you are
> actually developing agents which is a whole different ball game. I could
> certainly see adding a -XX argument that forces agentpath to load the
> external library which would be good for agent development and debugging.
> No need to relink the entire VM with the new agent. Our tech lead is out on
> vacation this week so I'll bring this up when he's back.
>
> bill
>
>
> On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE <bill.pittore at oracle.com <
> mailto:bill.pittore at oracle.com <bill.pittore at oracle.com>>> wrote:
>
>
>    These changes address bug 8014135 which adds support for
>
>    statically linked agents in the VM. This is a followup to the
>
>    recent JNI spec changes that addressed statically linked JNI
>
>    libraries( 8005716).
>
>    The JEP for this change is the same JEP as the JNI changes:
>
>    http://openjdk.java.net/jeps/178
>
>
>    Webrevs are here:
>
>
>    http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/
>
>    <http://cr.openjdk.java.net/%7Ebpittore/8014135/jdk/webrev.00/>
>
>     http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/
>
>    <http://cr.openjdk.java.net/%7Ebpittore/8014135/hotspot/webrev.00/>
>
>
>    The changes to jvmti.xml can also be seen in the output file that
>
>    I placed here:
>
>
> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html
>
>    <
> http://cr.openjdk.java.net/%7Ebpittore/8014135/hotspot/webrev.00/jvmti.html
> >
>
>
>    Thanks,
>
>    bill
>
>
>
>
>
>
>