Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
"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
I bet $100 it is not true :-)
Original comment by Andrei.Pozolotin
on 18 Jan 2013 at 3:19
"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
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
Andrei.Pozolotin
on 17 Jan 2013 at 5:51