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

[Jeremy Manson]

Okay.  I'd be happy to talk about what we did, if you think it would be of
interest.

All invocations of the JVM at Google use the same JVMTI agent.  We're
moving to a model where everyone builds their own launcher [1], so the
obvious thing for us to do was combine the launcher and the agent
statically, which simplifies our deployment and matches better with other
parts of the Google workflow.

However, we weren't too worried about people statically linking in multiple
agents, so we didn't put in support for that.  We will certainly use what
you are doing, since that gives us said support for free (plus, it will be
more work not to use it when we move to HS25).

In that model, having a VM flag to grab an agent out of the launcher makes
some sense, but it's also useful for people like me in debugging scenarios
to build a separate agent, pass it with -agentlib and/or -agentpath, and
override the one in the launcher.

Arguably, I'm not your use case.  Although, having said that, perhaps I am
- I'm the only one I know who is already statically linking JNI and JVMTI
in a production context!

[1]  Actually, they will build a single static self-executing JAR file
containing their own launcher, which statically links in all of their JNI
and our JVMTI agent, and all the classes their application needs.  There is
lots of overlap with JEP178, as you can see.

Jeremy


On Wed, Jul 10, 2013 at 12:29 PM, BILL PITTORE <bill.pittore at oracle.com>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>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/~bpittore/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
>>
>> Thanks,
>> bill
>>
>>
>>
>
>