Better error message for missing allocationinstrumenter agent jar

[GoogleCodeExporter]

Jan 17, 2013 11:49:38 AM com.google.caliper.config.LoggingConfigLoader 
loadLoggingConfig
INFO: Using logging configuration at /home/user1/.caliper/logging.properties
Experiment selection: 
  Instruments:   [AllocationInstrument, MicrobenchmarkInstrument]
  User parameters:   {arguments=[1, 2, 3, 4, 5, 6], strategy=[VARARGS, EXPANSION]}
  Virtual machines:  [default]
  Selection type:    Full cartesian product

This selection yields 24 experiments.
Measuring 1 trials each of 24 experiments. Estimated runtime: 2.9m.
java.lang.IllegalStateException: Can't find required allocationinstrumenter 
agent jar
    at com.google.caliper.runner.AllocationInstrument.getExtraCommandLineArgs(AllocationInstrument.java:84)
    at com.google.caliper.runner.ExperimentingCaliperRun.createWorkerProcessBuilder(ExperimentingCaliperRun.java:270)
    at com.google.caliper.runner.ExperimentingCaliperRun.measure(ExperimentingCaliperRun.java:297)
    at com.google.caliper.runner.ExperimentingCaliperRun.run(ExperimentingCaliperRun.java:209)
    at com.google.caliper.runner.CaliperMain.exitlessMain(CaliperMain.java:107)
    at com.google.caliper.runner.CaliperMain.main(CaliperMain.java:70)
    at com.google.caliper.runner.CaliperMain.main(CaliperMain.java:59)
    at com.google.caliper.Runner.main(Runner.java:445)
    at examples.VarargsBenchmark.main(VarargsBenchmark.java:238)

An unexpected exception has been thrown by the caliper runner.
Please see https://sites.google.com/site/caliperusers/issues

Original issue reported on code.google.com by Andrei.Pozolotin on 17 Jan 2013 at 5:51

[GoogleCodeExporter]

That obviously needs a better error message, but it's using 
instrument.allocation.options.allocationAgentJar=lib/allocation.jar to try to 
locate the jar.  Updating this property to point to the location of the jar 
(http://code.google.com/p/java-allocation-instrumenter/) should fix it.

Original comment by gak@google.com on 17 Jan 2013 at 8:27

• Changed title: Better error message for missing allocationinstrumenter agent jar
• Changed state: Accepted
• Added labels: Milestone-1.0, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

please consider embedding allocation.jar inside caliper.jar
and treat externally provided allocation.jar as optional
(do not fail if missing)

yes, you would have to extract it, but compared to all else
that is going in in caliper - it seems not a big deal.

Original comment by Andrei.Pozolotin on 17 Jan 2013 at 10:25

[GoogleCodeExporter]

I tried it.  Classloading weirdness between the java agent and the classpath 
make it easy for the agent to break silently (i.e. report 0's all the time).  
Putting the burden on users seems to be the only way to make sure that caliper 
isn't pulling the rug out from under them.

Original comment by gak@google.com on 17 Jan 2013 at 10:31

[GoogleCodeExporter]

I mean do not embed actual allocation.jar classes.

instead embed allocation.jar as binary resource inside the caliper.jar
then extract and place it outside as normal file, not part of any class path.

I am doing the same with multi platform native library delivery here, you are 
welcome to borrow relevant code:

https://github.com/barchart/barchart-udt/tree/master/barchart-udt-core/src/main/
java/com/barchart/udt/lib

Original comment by Andrei.Pozolotin on 17 Jan 2013 at 10:40

[GoogleCodeExporter]

I'm quite clear on what you meant.  It doesn't work for agents.

Original comment by gak@google.com on 17 Jan 2013 at 11:47

[GoogleCodeExporter]

"Putting the burden on users seems to be the only way..."  That's truly 
disappointing if true. :-(

Original comment by kevinb@google.com on 18 Jan 2013 at 3:05

[GoogleCodeExporter]

I bet $100 it is not true :-)

Original comment by Andrei.Pozolotin on 18 Jan 2013 at 3:19

[GoogleCodeExporter]

"Only" was a bad choice.  It should have been "most straightforward" or maybe 
"least fragile".  I'm sure there's some way that we could inspect classloaders 
and the like and/or inspect and alter the jars on the classpath.  Regardless, 
the strategy outlined in #2 doesn't work without some form of control over the 
classpath provided to the worker.

Something worth considering may be trying to detect the presence of the agent 
jar on the classpath of the runner and using _that_ if it's present.  I'm 
somewhat strongly opposed to trying to mangle the classpath, but finding the 
agent on the user's untouched classpath might work.

In any case, it's probably a good idea to test for the correct behavior of the 
agent at runtime.  I'm going to file a bug since the agent code will dutifully 
report 0 allocations rather than errors and even with people filling out the 
value manually, there's still decent potential to screw it up.

Original comment by gak@google.com on 18 Jan 2013 at 5:49

[GoogleCodeExporter]

thank you.

probably should also file a bug for "embed allocation.jar" 
to re-visit this later.

Original comment by Andrei.Pozolotin on 18 Jan 2013 at 5:35

[GoogleCodeExporter]

I have embedded allocation.jar in caliper.jar

http://code.google.com/r/andreipozolotin-allocation-jar/source/detail?r=be25ab72
5d1ae2bf2c8764c80b5e9973d21a9ef9

is there a way to send this you as a pull request?

Original comment by Andrei.Pozolotin on 22 Jan 2013 at 9:09

[GoogleCodeExporter]

I've done it as well.  The part where you actually move the jar around is 
relatively trivial, but there is a failure scenario (2 copies of the jar: 1 as 
the agent and 1 on the classpath) that will just silently report 0s for all of 
its measurements with this change.  This is a very real issue and is why the 
change I'd made was reverted.  Inaccurate measurements are unacceptable.

It could possibly be made safe safe if:
1) If we can detect that the instrument isn't working as intended (issue 203)
2) If we can make sure that we're not about to _cause_ that problem, in which 
case we can just use the other jar anyway (issue 204)

I've created issue 205 with those two as blockers to make the dependencies 
explicit.  This issue will remain as-is since the error message still needs to 
be addressed.

Original comment by gak@google.com on 22 Jan 2013 at 9:36

[GoogleCodeExporter]

I do not understand the nature of the problem.
how can I reproduce it? can you commit unit test for it?

-javaagent:file:/absolute/path-one/to/allocation.jar

should have no relationship with the

-cp jar:file:/absolute/path-two/to/caliper.jar!/lib/allocation.jar

will renaming
/lib/allocation.jar -> /lib/allocation.bin
inside the caliper.jar help to resolve the "mysterious issue"?

Original comment by Andrei.Pozolotin on 22 Jan 2013 at 11:58

[GoogleCodeExporter]

BTW: it seems agent jar is not build properly:

http://docs.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.ht
ml

-------------
...
"The manifest of the agent JAR file must contain the attribute Premain-Class."
...
"Premain-Class
When an agent is specified at JVM launch time this attribute specifies the 
agent class. That is, the class containing the premain method. When an agent is 
specified at JVM launch time this attribute is required. If the attribute is 
not present the JVM will abort. Note: this is a class name, not a file name or 
path."
...
-------------

while this
http://search.maven.org/remotecontent?filepath=com/google/code/java-allocation-i
nstrumenter/java-allocation-instrumenter/2.0/java-allocation-instrumenter-2.0.ja
r

have only
--------------
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: inder
Build-Jdk: 1.6.0_24
--------------

also: did you try Agent-Class/agentmain() ?

Original comment by Andrei.Pozolotin on 23 Jan 2013 at 12:32

[GoogleCodeExporter]

RE: #12
It all boils down to classloading.  "The agent class will be loaded by the 
system class loader (see ClassLoader.getSystemClassLoader). This is the class 
loader which typically loads the class containing the application main method." 

http://docs.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.ht
ml

RE: #13
Any concerns with the agent jar should be filed at 
http://code.google.com/p/java-allocation-instrumenter/

Original comment by gak@google.com on 23 Jan 2013 at 4:30

[GoogleCodeExporter]

ok, filed
http://code.google.com/p/java-allocation-instrumenter/issues/detail?id=11

Original comment by Andrei.Pozolotin on 23 Jan 2013 at 8:32

[GoogleCodeExporter]

nice people of allocation project
http://code.google.com/p/java-allocation-instrumenter/issues/detail?id=11

released corrected artifact
http://search.maven.org/#search%7Cga%7C1%7Cjava-allocation-instrumenter

I hope this takes care of the "mysterious issue"

Original comment by Andrei.Pozolotin on 25 Jan 2013 at 4:08

[GoogleCodeExporter]

I have pushed a change that attempts to look for the allocation instrument jar 
on the classpath of the parent and uses that if present.  Hopefully, this 
should simplify things in the common case.  Embedding the jar is still in the 
works, but will only be used if the agent jar isn't on that classpath.  The 
configuration option is still available to override that jar if desired.

Original comment by gak@google.com on 4 Apr 2013 at 9:14

• Changed state: Started

[GoogleCodeExporter]

There was a bug in the latest revision.  A fix will be pushed shortly.

Original comment by gak@google.com on 4 Apr 2013 at 9:41

[GoogleCodeExporter]

There is now also an uber jar (generated with the maven shade plugin) that is 
both the Caliper app _and_ the agent jar.  I believe that that jar and the 
classpath searching probably covers all of the use cases, so I'm going to mark 
this fixed.  If there's another situation in which this is still causing you 
trouble, let me know and I'll gladly reopen this issue.

Original comment by gak@google.com on 11 Apr 2013 at 10:50

• Changed state: Fixed

[GoogleCodeExporter]

Actually, it looks like this was prematurely closed as I never actually updated 
the message.  :-\  Everything else got better, but not the text.  Oops.  This 
should come shortly.

Original comment by gak@google.com on 20 May 2013 at 5:49

• Changed state: Started