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

[Bob Vandette]

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