From ecki at zusammenkunft.net Tue May 12 23:42:19 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 13 May 2015 01:42:19 +0200 Subject: jol-cli and external class path Message-ID: <20150513014219.0000177d.ecki@zusammenkunft.net> Hello, I noticed that on the JOL homepage the jol-cli samples all use the -jar executable form. With this it is not possible to specify additional classes on the class path. Is there a way to do it, or is it allowed/expected to use java -cp in this case? Should this be documented? I noticed there is some pre-main instrumentation in the JAR, so do I need to specify an -javaagent as well? The tests I tried worked without: java -cp target\classes;jol-cli-full.jar org.openjdk.jol.Main internals test.MyClass From JMH I know that is imortant to have the benchmark.jar, but JOL looks less demanding in that regard. Gruss Bernd PS: I was digging into this because I wanted to give some help on a SO answer, so thats why I thought using the -cli variant might be easier to explain. http://stackoverflow.com/a/30203163/13189 From aleksey.shipilev at oracle.com Wed May 13 09:13:22 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 13 May 2015 12:13:22 +0300 Subject: jol-cli and external class path In-Reply-To: <20150513014219.0000177d.ecki@zusammenkunft.net> References: <20150513014219.0000177d.ecki@zusammenkunft.net> Message-ID: <555315B2.5040206@oracle.com> Hi, On 05/13/2015 02:42 AM, Bernd Eckenfels wrote: > I noticed that on the JOL homepage the jol-cli samples all use the -jar > executable form. With this it is not possible to specify additional > classes on the class path. > > Is there a way to do it, or is it allowed/expected to use java -cp in > this case? Should this be documented? Yes, at the moment, that's the way you do it, classpath the JOL JAR, and explicitly enter the Main JOL method. There might be a better way, but I can't clearly see it now. We can probably accept our own classpath line and set up our own URLClassLoader to pull the selected classes from there, like: $ java -jar jol-cli.jar internals -cp myjar.jar:myjar2.jar test.MyClass $ java -jar jol-cli.jar internals -cp target/classes test.MyClass > I noticed there is some pre-main instrumentation in the JAR, so do I > need to specify an -javaagent as well? Actually, javaagent should self-attach even without -javaagent on the command line. > The tests I tried worked without: > > java -cp target\classes;jol-cli-full.jar org.openjdk.jol.Main > internals test.MyClass Yeah, that should do it. -Aleksey From aleksey.shipilev at oracle.com Wed May 13 12:18:32 2015 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Wed, 13 May 2015 12:18:32 +0000 Subject: hg: code-tools/jol: 7901419: jol-cli should provide the means to specify the classpath Message-ID: <201505131218.t4DCIWQs024387@aojmv0008.oracle.com> Changeset: 23eb6c92ad4e Author: shade Date: 2015-05-13 15:18 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/23eb6c92ad4e 7901419: jol-cli should provide the means to specify the classpath ! jol-cli/pom.xml + jol-cli/src/main/java/org/openjdk/jol/OptionFormatter.java + jol-cli/src/main/java/org/openjdk/jol/operations/ClasspathedOPeration.java ! jol-cli/src/main/java/org/openjdk/jol/operations/ObjectEstimates.java ! jol-cli/src/main/java/org/openjdk/jol/operations/ObjectExternals.java ! jol-cli/src/main/java/org/openjdk/jol/operations/ObjectFootprint.java ! jol-cli/src/main/java/org/openjdk/jol/operations/ObjectInternals.java From aleksey.shipilev at oracle.com Wed May 13 12:21:51 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 13 May 2015 15:21:51 +0300 Subject: jol-cli and external class path In-Reply-To: <555315B2.5040206@oracle.com> References: <20150513014219.0000177d.ecki@zusammenkunft.net> <555315B2.5040206@oracle.com> Message-ID: <555341DF.5060802@oracle.com> On 13.05.2015 12:13, Aleksey Shipilev wrote: > On 05/13/2015 02:42 AM, Bernd Eckenfels wrote: >> I noticed that on the JOL homepage the jol-cli samples all use the -jar >> executable form. With this it is not possible to specify additional >> classes on the class path. >> >> Is there a way to do it, or is it allowed/expected to use java -cp in >> this case? Should this be documented? > > Yes, at the moment, that's the way you do it, classpath the JOL JAR, and > explicitly enter the Main JOL method. > > There might be a better way, but I can't clearly see it now. We can > probably accept our own classpath line and set up our own URLClassLoader > to pull the selected classes from there, like: > > $ java -jar jol-cli.jar internals -cp myjar.jar:myjar2.jar test.MyClass > $ java -jar jol-cli.jar internals -cp target/classes test.MyClass Yes, this is it: https://bugs.openjdk.java.net/browse/CODETOOLS-7901419 http://hg.openjdk.java.net/code-tools/jol/rev/23eb6c92ad4e Bernd, can you build JOL from source and tell if that covers your scenarios? General review is also appreciated. If everything is fine, we can arrange the 0.3.3 release with this on-board. Thanks, -Aleksey. From aleksey.shipilev at oracle.com Wed May 13 12:27:21 2015 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Wed, 13 May 2015 12:27:21 +0000 Subject: hg: code-tools/jol: Make sure LICENSE and THIRD-PARTY is available in all JARs and subprojects. Message-ID: <201505131227.t4DCRL6D026612@aojmv0008.oracle.com> Changeset: 1ae450a74f19 Author: shade Date: 2015-05-13 15:26 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/1ae450a74f19 Make sure LICENSE and THIRD-PARTY is available in all JARs and subprojects. + THIRD-PARTY + jol-cli/LICENSE + jol-cli/THIRD-PARTY + jol-cli/src/main/resources/THIRD-PARTY + jol-core/LICENSE + jol-core/THIRD-PARTY + jol-core/src/main/resources/THIRD-PARTY + jol-samples/LICENSE + jol-samples/THIRD-PARTY + jol-samples/src/resources/THIRD-PARTY From brianfromoregon at gmail.com Wed May 13 20:21:33 2015 From: brianfromoregon at gmail.com (Brian Harris) Date: Wed, 13 May 2015 13:21:33 -0700 Subject: GraphLayout with multiple roots Message-ID: Hi, What do you think about adding GraphLayout.parseInstances(Object... roots)? I'd like to measure totalSize of multiple instances and avoid double counting when they both have reference to same subgraph. Thanks, Brian From ecki at zusammenkunft.net Thu May 14 05:02:30 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 May 2015 07:02:30 +0200 Subject: jol-cli and external class path In-Reply-To: <555341DF.5060802@oracle.com> References: <20150513014219.0000177d.ecki@zusammenkunft.net> <555315B2.5040206@oracle.com> <555341DF.5060802@oracle.com> Message-ID: <20150514070230.00005b4a.ecki@zusammenkunft.net> Am Wed, 13 May 2015 15:21:51 +0300 schrieb Aleksey Shipilev : > Yes, this is it: > https://bugs.openjdk.java.net/browse/CODETOOLS-7901419 > http://hg.openjdk.java.net/code-tools/jol/rev/23eb6c92ad4e > > Bernd, can you build JOL from source and tell if that covers your > scenarios? General review is also appreciated. If everything is fine, > we can arrange the 0.3.3 release with this on-board. Thanks for the quick fix. I compiled 0.4-SNAPSHOT (49:1ae450a74f19) in Maven 3.2.5 / Java 8 / Win64 cleanly. It also works as advertised, I can add relativ or absolute directories or JAR files to the external -cp, and it can inspect classes from the external CP as well as internal (as well as [C syntax). This is better to use. (the jol-cli.jar is not names jol-cli-full.jar, is that expected?) I intuitively used "java -jar jol-cli.jar -cp ... internals test.Test" first. From the help and source it is clear that it does not work and I guess it is acceptable. (On the other hand, conceptionally -cp would be a "global" option, independend of the mode? An unknown mode (-cp) should maybe also show the Usage: help in addition to the mode list: Currently: $ java -jar jol-cli\target\jol-cli.jar -cp .. Available modes: estimates: Simulate the class layout in different VM modes. externals: Show the object externals: the objects reachable from a given instance. footprint: Estimate the footprint of all objects reachable from a given instance heapdump: Consume the heap dump and estimate the savings in different layout strategies. idealpack: Compute the object footprint under different field layout strategies. internals: Show the object internals: field layout and default contents, object header string-compress: Consume the heap dumps and figures out the savings attainable with compressed strings. Unknown mode: -cp Better(?): $ java -jar jol-cli\target\jol-cli.jar -cp ..\..\\asf\test\target\classes Usage: jol-cli.jar [optional arguments]* Available modes: estimates: Simulate the class layout in different VM modes. externals: Show the object externals: the objects reachable from a given instance. footprint: Estimate the footprint of all objects reachable from a given instance heapdump: Consume the heap dump and estimate the savings in different layout strategies. idealpack: Compute the object footprint under different field layout strategies. internals: Show the object internals: field layout and default contents, object header string-compress: Consume the heap dumps and figures out the savings attainable with compressed strings. Unknown mode: -cp Gruss Bernd From ecki at zusammenkunft.net Thu May 14 05:14:57 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 May 2015 07:14:57 +0200 Subject: IBM JDK crash(Win) with internals Message-ID: <20150514071457.00006644.ecki@zusammenkunft.net> Hello, not sure if it is relevant here, but I thought I would mention it. While trying out the new JOL snapshot, I also tried it with some (Windows) IBM JDK. And while "footprint java.lang.String" works fine: >"\Program Files\Java\ibm_sdk70\bin\java.exe" -jar jol-cli\target\jol-cli.jar footprint java.lang.String Running 64-bit Auto-detected VM. Using compressed references with 1-bit shift. Objects are 3 bytes aligned. Field sizes by type: 4, 4, 4, 4, 4, 4, 4, 8, 8 [bytes] Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes] java.lang.String instance footprint: COUNT AVG SUM DESCRIPTION 1 18 18 [C 1 33 33 java.lang.String 2 51 (total) (should we maybe print the JVM vendor+version in the "Running" line?) The JVM crashes with a general protection fault with internals: >"\Program Files\Java\ibm_sdk70\bin\java.exe" -jar jol-cli\target\jol-cli.jar internals java.lang.String Running 64-bit Auto-detected VM. Using compressed references with 1-bit shift. Objects are 3 bytes aligned. Field sizes by type: 4, 4, 4, 4, 4, 4, 4, 8, 8 [bytes] Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes] Unhandled exception Type=Segmentation error vmState=0x00000000 Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=000007FEEEA7AA25 ContextFlags=0010001f Handler1=000007FEF44337D0 Handler2=000007FEF5AE1600 ... Module=C:\Program Files\Java\ibm_sdk70\jre\bin\compressedrefs\jclse7b_26.dll Module_base_address=000007FEEEA40000 Offset_in_DLL=000000000003aa25 Target=2_60_20131013_170512 (Windows 7 6.1 build 7601 Service Pack 1) CPU=amd64 (8 logical CPUs) (0x1fbdda000 RAM) # java full version JRE 1.7.0 IBM Windows AMD 64 build pwa6470sr6-20131015_01(SR6) The Windows Version of that JVM is a bit hard to get by, so it might not be the latest version, but perhaps somebofy from IBM is lurking here. Gruss Bernd From ecki at zusammenkunft.net Thu May 14 05:21:55 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 May 2015 07:21:55 +0200 Subject: IBM JDK crash(Win) with internals In-Reply-To: <20150514071457.00006644.ecki@zusammenkunft.net> References: <20150514071457.00006644.ecki@zusammenkunft.net> Message-ID: <20150514072155.00007550.ecki@zusammenkunft.net> Am Thu, 14 May 2015 07:14:57 +0200 schrieb Bernd Eckenfels : > While trying out the new JOL snapshot, I also tried it with some > (Windows) IBM JDK. Just to make it clear, it is not limited to the SNAPSHOT, the 0.3.1 also reproduces the crash on that IBM JVM. Gruss Bernd From aleksey.shipilev at oracle.com Thu May 14 07:39:37 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 14 May 2015 10:39:37 +0300 Subject: IBM JDK crash(Win) with internals In-Reply-To: <20150514071457.00006644.ecki@zusammenkunft.net> References: <20150514071457.00006644.ecki@zusammenkunft.net> Message-ID: <55545139.7060904@oracle.com> On 05/14/2015 08:14 AM, Bernd Eckenfels wrote: > While trying out the new JOL snapshot, I also tried it with some > (Windows) IBM JDK. And while "footprint java.lang.String" works fine: > >> "\Program Files\Java\ibm_sdk70\bin\java.exe" -jar jol-cli\target\jol-cli.jar footprint java.lang.String > Running 64-bit Auto-detected VM. > Using compressed references with 1-bit shift. > Objects are 3 bytes aligned. 3-byte alignment also seems wrong. Anyhow, JOL is only supported for OpenJDK-based VMs, and we don't target to support anything else. It is using a very specific sort of magic to get the results, which may be not portable across JVMs. That said, if you can diagnose the issue and it points to a legitimate JOL bug, we'll gladly fix it. > ...but perhaps somebody from IBM is lurking here. Seems unlikely to me. Thanks, -Aleksey From aleksey.shipilev at oracle.com Thu May 14 08:51:15 2015 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Thu, 14 May 2015 08:51:15 +0000 Subject: hg: code-tools/jol: 7901422: GraphLayout.parseInstance should accept multiple roots Message-ID: <201505140851.t4E8pFM7002068@aojmv0008.oracle.com> Changeset: 9c716b63a6cf Author: shade Date: 2015-05-14 11:51 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/9c716b63a6cf 7901422: GraphLayout.parseInstance should accept multiple roots ! jol-core/src/main/java/org/openjdk/jol/info/GraphLayout.java ! jol-core/src/main/java/org/openjdk/jol/info/GraphWalker.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_16_AL_LL.java From aleksey.shipilev at oracle.com Thu May 14 08:52:06 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 14 May 2015 11:52:06 +0300 Subject: GraphLayout with multiple roots In-Reply-To: References: Message-ID: <55546236.2010008@oracle.com> On 05/13/2015 11:21 PM, Brian Harris wrote: > What do you think about adding GraphLayout.parseInstances(Object... roots)? > I'd like to measure totalSize of multiple instances and avoid double > counting when they both have reference to same subgraph. I don't see why not: https://bugs.openjdk.java.net/browse/CODETOOLS-7901422 http://hg.openjdk.java.net/code-tools/jol/rev/9c716b63a6cf -Aleksey From aleksey.shipilev at oracle.com Thu May 14 09:14:03 2015 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Thu, 14 May 2015 09:14:03 +0000 Subject: hg: code-tools/jol: 7901423: jol-cli should print help messages on errors properly Message-ID: <201505140914.t4E9E3F1006472@aojmv0008.oracle.com> Changeset: c5320bbe2181 Author: shade Date: 2015-05-14 12:13 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/c5320bbe2181 7901423: jol-cli should print help messages on errors properly ! jol-cli/src/main/java/org/openjdk/jol/Main.java ! jol-cli/src/main/java/org/openjdk/jol/operations/ClasspathedOPeration.java From aleksey.shipilev at oracle.com Thu May 14 09:16:15 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 14 May 2015 12:16:15 +0300 Subject: jol-cli and external class path In-Reply-To: <20150514070230.00005b4a.ecki@zusammenkunft.net> References: <20150513014219.0000177d.ecki@zusammenkunft.net> <555315B2.5040206@oracle.com> <555341DF.5060802@oracle.com> <20150514070230.00005b4a.ecki@zusammenkunft.net> Message-ID: <555467DF.1000809@oracle.com> On 05/14/2015 08:02 AM, Bernd Eckenfels wrote: > Thanks for the quick fix. I compiled 0.4-SNAPSHOT (49:1ae450a74f19) in > Maven 3.2.5 / Java 8 / Win64 cleanly. > > It also works as advertised, I can add relativ or absolute directories > or JAR files to the external -cp, and it can inspect classes from the > external CP as well as internal (as well as [C syntax). This is better to use. Thanks for testing! > (the jol-cli.jar is not names jol-cli-full.jar, is that expected?) Yeah, locally-built uberjar is "jol-cli.jar", but it gets published to Central with "full" classifier. > I intuitively used "java -jar jol-cli.jar -cp ... internals test.Test" > first. From the help and source it is clear that it does not work and I > guess it is acceptable. (On the other hand, conceptionally -cp would be > a "global" option, independend of the mode? It's not a global option. Some modes do not care about classpath at all. > An unknown mode (-cp) should maybe also show the Usage: help in > addition to the mode list: Yes, done: https://bugs.openjdk.java.net/browse/CODETOOLS-7901423 Thanks, -Aleksey. From brianfromoregon at gmail.com Thu May 14 19:00:40 2015 From: brianfromoregon at gmail.com (Brian Harris) Date: Thu, 14 May 2015 12:00:40 -0700 Subject: dynamic attach fails when using intellij dynamic classpath Message-ID: Hi, jol's (cool!) dynamic agent attach feature seems to fail inside Intellij when Intellij is told to launch jvm using classpath file. This is done by setting dynamic.classpath property to true inside workspace.xml. More detail including link to intellij's JdkUtil class that looks at this setting: http://stackoverflow.com/questions/4853540/what-does-the-dynamic-classpath-flag-do-intellij-project-settings The failure looks like this: D:\tools\jdk1.8.0_20\bin\java -ea -Didea.launcher.port=7536 "-Didea.launcher.bin.path=D:\tools\IntelliJ IDEA Community Edition 14.1.1\bin" -classpath "D:\tools\IntelliJ IDEA Community Edition 14.1.1\lib\idea_rt.jar;D:\tools\IntelliJ IDEA Community Edition 14.1.1\lib\util.jar" -Dfile.encoding=windows-1252 com.intellij.rt.execution.CommandLineWrapper C:\Users\Harris\AppData\Local\Temp\classpath0.tmp com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 com.brianfromoregon.MainTest,test java.lang.ClassNotFoundException: org.openjdk.jol.util.InstrumentationSupport$Installer at java.net.URLClassLoader$1.run(URLClassLoader.java:372) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:304) at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411) Agent failed to start! Exception in thread "Attach Listener" Process finished with exit code 0 When I set dynamic.classpath to false, then the error goes away. D:\tools\jdk1.8.0_20\bin\java -ea -Didea.launcher.port=7537 "-Didea.launcher.bin.path=D:\tools\IntelliJ IDEA Community Edition 14.1.1\bin" -Dfile.encoding=windows-1252 -classpath "D:\tools\IntelliJ IDEA Community Edition 14.1.1\lib\idea_rt.jar;D:\tools\IntelliJ IDEA Community Edition 14.1.1\plugins\junit\lib\junit-rt.jar;D:\tools\jdk1.8.0_20\jre\lib\charsets.jar;D:\tools\jdk1.8.0_20\jre\lib\deploy.jar;D:\tools\jdk1.8.0_20\jre\lib\javaws.jar;D:\tools\jdk1.8.0_20\jre\lib\jce.jar;D:\tools\jdk1.8.0_20\jre\lib\jfr.jar;D:\tools\jdk1.8.0_20\jre\lib\jfxswt.jar;D:\tools\jdk1.8.0_20\jre\lib\jsse.jar;D:\tools\jdk1.8.0_20\jre\lib\management-agent.jar;D:\tools\jdk1.8.0_20\jre\lib\plugin.jar;D:\tools\jdk1.8.0_20\jre\lib\resources.jar;D:\tools\jdk1.8.0_20\jre\lib\rt.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\access-bridge-64.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\cldrdata.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\dnsns.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\jaccess.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\jfxrt.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\localedata.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\nashorn.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\sunec.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\sunjce_provider.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\sunmscapi.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\sunpkcs11.jar;D:\tools\jdk1.8.0_20\jre\lib\ext\zipfs.jar;C:\Users\Harris\code\jol-tests\target\test-classes;C:\Users\Harris\code\jol-tests\target\classes;D:\tools\IntelliJ IDEA Community Edition 14.1.1\lib\junit-4.11.jar;D:\tools\IntelliJ IDEA Community Edition 14.1.1\lib\hamcrest-core-1.3.jar;D:\tools\IntelliJ IDEA Community Edition 14.1.1\lib\hamcrest-library-1.3.jar;F:\maven-repo\org\openjdk\jol\jol-core\0.3.1\jol-core-0.3.1.jar" com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 com.brianfromoregon.MainTest,test Process finished with exit code 0 I have tested with Intellij versions 12,13,14. Any ideas what the problem is? Using debugger I can see that it blows up on this line inside org.openjdk.jol.util.InstrumentationSupport#tryDynamicAttach vmClass.getDeclaredMethod("loadAgent", String.class, String.class) .invoke(vm, agentFile.getAbsolutePath(), ""); However, debugger shows seemingly equivalent values for vmClass and vm and agentFile in both pass and fail scenarios, so I'm a bit stuck. From aleksey.shipilev at oracle.com Fri May 15 10:59:27 2015 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Fri, 15 May 2015 10:59:27 +0000 Subject: hg: code-tools/jol: 7901425: Dynamic attach fails when using IDEA dynamic.classpath Message-ID: <201505151059.t4FAxRXS004872@aojmv0008.oracle.com> Changeset: 9d15f184835e Author: shade Date: 2015-05-15 13:59 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/9d15f184835e 7901425: Dynamic attach fails when using IDEA dynamic.classpath Summary: Fix a few corner cases in dynamic attach code. ! jol-core/src/main/java/org/openjdk/jol/util/InstrumentationSupport.java From aleksey.shipilev at oracle.com Fri May 15 11:02:53 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 15 May 2015 14:02:53 +0300 Subject: dynamic attach fails when using intellij dynamic classpath In-Reply-To: References: Message-ID: <5555D25D.8060406@oracle.com> Hi, On 05/14/2015 10:00 PM, Brian Harris wrote: > I have tested with Intellij versions 12,13,14. Any ideas what the problem > is? Using debugger I can see that it blows up on this line > inside org.openjdk.jol.util.InstrumentationSupport#tryDynamicAttach > > vmClass.getDeclaredMethod("loadAgent", String.class, String.class) > .invoke(vm, agentFile.getAbsolutePath(), ""); > > > However, debugger shows seemingly equivalent values for vmClass and vm and > agentFile in both pass and fail scenarios, so I'm a bit stuck. Actually, that code delivers a few "legitimate" exceptions that are ignored in InstrumentationSupport.instance(). Adding "ignored.printStackTrace()" there helps to diagnose the issues. I have pushed two minor corrections to our dynamic attach code, and at least my IDEA 14 now works fine with "dynamic.classpath" = true. See: https://bugs.openjdk.java.net/browse/CODETOOLS-7901425 http://hg.openjdk.java.net/code-tools/jol/rev/9d15f184835e We are going to release next patch update soon (today), so please check this out as soon as possible. Thanks, -Aleksey. From aleksey.shipilev at oracle.com Fri May 15 17:02:00 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 15 May 2015 20:02:00 +0300 Subject: JOL 0.3.2 Message-ID: <55562688.3050503@oracle.com> Hi, JOL 0.3.2 is released and available at Maven Central (thanks to Evgeny Mandrikov, as always!). This is a minor patch release. Summary of changes: * jol-cli now provides the means to specify the class path where to look for the inspected classes. This saves a (weird) trip to constructing the exploded classpath with JOL onboard, and figuring out the JOL entiry point. Tracking: https://bugs.openjdk.java.net/browse/CODETOOLS-7901419 Works like this: $ java -jar jol-cli.jar internals -cp myjar.jar:myjar2.jar test.MyClass $ java -jar jol-cli.jar internals -cp target/classes test.MyClass * GraphLayout.parseInstance now accepts multiple roots. This helps to avoid double-counting when some objects are reachable from both roots. Tracking: https://bugs.openjdk.java.net/browse/CODETOOLS-7901422 * Dynamic agent attach was broken in non-trivial classloading setups. For example, when running from IDEA. Fixed: https://bugs.openjdk.java.net/browse/CODETOOLS-7901425 * A few touchups in the samples and CLI interface. Enjoy! Thanks, -Aleksey. From aleksey.shipilev at oracle.com Fri May 15 17:02:27 2015 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Fri, 15 May 2015 17:02:27 +0000 Subject: hg: code-tools/jol: 3 new changesets Message-ID: <201505151702.t4FH2RwL011605@aojmv0008.oracle.com> Changeset: 6670ac8be7a5 Author: shade Date: 2015-05-15 14:20 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/6670ac8be7a5 JOL v0.3.2. ! jol-cli/pom.xml ! jol-core/pom.xml ! jol-samples/pom.xml ! pom.xml Changeset: e40a7fc4fb59 Author: shade Date: 2015-05-15 14:20 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/e40a7fc4fb59 Added tag 0.3.2 for changeset 6670ac8be7a5 ! .hgtags Changeset: a6a3bf9b6636 Author: shade Date: 2015-05-15 14:21 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/a6a3bf9b6636 Continue in 0.4-SNAPSHOT. ! jol-cli/pom.xml ! jol-core/pom.xml ! jol-samples/pom.xml ! pom.xml