From aleksey.shipilev at oracle.com Wed Nov 5 17:05:34 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Wed, 05 Nov 2014 17:05:34 +0000 Subject: hg: code-tools/jol: Fix regressed jol-estimates output. Message-ID: <201411051705.sA5H5YFN015849@aojmv0008> Changeset: 74fcfa26ecc4 Author: shade Date: 2014-11-05 20:05 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/74fcfa26ecc4 Fix regressed jol-estimates output. ! jol-cli/src/main/java/org/openjdk/jol/MainObjectEstimates.java From nyigitbasi at netflix.com Wed Nov 5 19:33:29 2014 From: nyigitbasi at netflix.com (Nezih Yigitbasi) Date: Wed, 5 Nov 2014 11:33:29 -0800 Subject: problem with ClassLayout.parseClass Message-ID: Hi everyone, We are seeing a weird GC problem with the jol library with the ClassLayout.parseClass() call. The problem is that the calling thread spends a lot of time doing full GCs and it?s kind of stuck in a GC loop. We only observed this problem with the -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags where the explicit System.gc() call in the VMSupport.guessAlignment() method cause full GCs that are very slow (when these flags are removed I see less number of full GCs that are much faster and I don?t see the problem anymore). This seemed like a bug to me, but I just wanted to check with you to understand it better. Our current workaround is to disable explicit GC calls. Btw my environment is EC2/Linux with openjdk 1.7. Thanks, Nezih "main" prio=10 tid=0x00007fe1d8019000 nid=0x4aeb runnable [0x00007fe1dee84000] java.lang.Thread.State: RUNNABLE at java.lang.Runtime.gc(Native Method) at java.lang.System.gc(System.java:984) at org.openjdk.jol.util.VMSupport.guessAlignment(VMSupport.java:226) at org.openjdk.jol.util.VMSupport.access$1500(VMSupport.java:56) at org.openjdk.jol.util.VMSupport$VMOptions.(VMSupport.java:335) at org.openjdk.jol.util.VMSupport$VMOptions.getHotspotSpecifics(VMSupport.java:395) at org.openjdk.jol.util.VMSupport$VMOptions.getOptions(VMSupport.java:350) at org.openjdk.jol.util.VMSupport$VMOptions.access$000(VMSupport.java:304) at org.openjdk.jol.util.VMSupport.(VMSupport.java:115) at org.openjdk.jol.info.FieldData.computeOffset(FieldData.java:80) at org.openjdk.jol.info.FieldData.parse(FieldData.java:58) at org.openjdk.jol.info.ClassData.parseClass(ClassData.java:87) at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:59) at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:48) at com.facebook.presto.ml.LearnStateFactory.(LearnStateFactory.java:28) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.facebook.presto.operator.aggregation.state.StateCompiler.generateStateFactory(StateCompiler.java:348) at com.facebook.presto.operator.aggregation.AggregationCompiler.generateAggregationFunctions(AggregationCompiler.java:108) at com.facebook.presto.operator.aggregation.GenericAggregationFunctionFactory.fromAggregationDefinition(GenericAggregationFunctionFactory.java:34) at com.facebook.presto.metadata.FunctionListBuilder.aggregate(FunctionListBuilder.java:129) at com.facebook.presto.ml.MLFunctionFactory.listFunctions(MLFunctionFactory.java:36) at com.facebook.presto.server.PluginManager.installPlugin(PluginManager.java:211) at com.facebook.presto.server.PluginManager.loadPlugin(PluginManager.java:179) at com.facebook.presto.server.PluginManager.loadPlugin(PluginManager.java:162) at com.facebook.presto.server.PluginManager.loadPlugins(PluginManager.java:145) at com.facebook.presto.server.PrestoServer.run(PrestoServer.java:111) at com.facebook.presto.server.PrestoServer.main(PrestoServer.java:61) ? From aleksey.shipilev at oracle.com Wed Nov 5 20:27:05 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Nov 2014 23:27:05 +0300 Subject: problem with ClassLayout.parseClass In-Reply-To: References: Message-ID: <545A8819.1030307@oracle.com> Hi Nezih, On 05.11.2014 22:33, Nezih Yigitbasi wrote: > We are seeing a weird GC problem with the jol library with the > ClassLayout.parseClass() call. The problem is that the calling > thread spends a lot of time doing full GCs and it?s kind of stuck in > a GC loop. We only observed this problem with the > -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags > where the explicit System.gc() call in the VMSupport.guessAlignment() > method cause full GCs that are very slow (when these flags are > removed I see less number of full GCs that are much faster and I > don?t see the problem anymore). This seemed like a bug to me, but I > just wanted to check with you to understand it better. Well, that code is running once during the initialization, and it does indeed calls for GC to condense the newly allocated array with objects to better estimate the alignment. I would agree that unexpected System.gc coming from a library is a library bug, and therefore we can revisit this, filed: https://bugs.openjdk.java.net/browse/CODETOOLS-7901085 -Aleksey. From nyigitbasi at netflix.com Wed Nov 5 20:37:05 2014 From: nyigitbasi at netflix.com (Nezih Yigitbasi) Date: Wed, 5 Nov 2014 12:37:05 -0800 Subject: problem with ClassLayout.parseClass In-Reply-To: <545A8819.1030307@oracle.com> References: <545A8819.1030307@oracle.com> Message-ID: Hi Aleksey, Thanks for the quick reply and opening the bug report. I will definitely give it another try once it?s fixed. The actual call made is ClassLayout.parseClass(ArrayList.class).instanceSize() to determine the size of an arraylist instance. Is there another method in jol that we can use to work around this problem instead of disabling explicit gc calls in production? Thanks again, Nezih ? On Wed, Nov 5, 2014 at 12:27 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > Hi Nezih, > > On 05.11.2014 22:33, Nezih Yigitbasi wrote: > > We are seeing a weird GC problem with the jol library with the > > ClassLayout.parseClass() call. The problem is that the calling > > thread spends a lot of time doing full GCs and it?s kind of stuck in > > a GC loop. We only observed this problem with the > > -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags > > where the explicit System.gc() call in the VMSupport.guessAlignment() > > method cause full GCs that are very slow (when these flags are > > removed I see less number of full GCs that are much faster and I > > don?t see the problem anymore). This seemed like a bug to me, but I > > just wanted to check with you to understand it better. > > Well, that code is running once during the initialization, and it does > indeed calls for GC to condense the newly allocated array with objects > to better estimate the alignment. > > I would agree that unexpected System.gc coming from a library is a > library bug, and therefore we can revisit this, filed: > https://bugs.openjdk.java.net/browse/CODETOOLS-7901085 > > -Aleksey. > > From aleksey.shipilev at oracle.com Wed Nov 5 20:40:53 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Wed, 05 Nov 2014 20:40:53 +0000 Subject: hg: code-tools/jol: 7901085: VMSupport.guessAlignment calls System.gc, deteriorates performance when used as a library Message-ID: <201411052040.sA5Ker9B025321@aojmv0008> Changeset: c58aecad901f Author: shade Date: 2014-11-05 23:40 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/c58aecad901f 7901085: VMSupport.guessAlignment calls System.gc, deteriorates performance when used as a library Summary: Revisit the guessAlignment implementation, get rid of System.gc. ! jol-core/src/main/java/org/openjdk/jol/util/MathUtil.java ! jol-core/src/main/java/org/openjdk/jol/util/VMSupport.java From aleksey.shipilev at oracle.com Wed Nov 5 20:41:54 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Nov 2014 23:41:54 +0300 Subject: problem with ClassLayout.parseClass In-Reply-To: <545A8819.1030307@oracle.com> References: <545A8819.1030307@oracle.com> Message-ID: <545A8B92.9030602@oracle.com> On 05.11.2014 23:27, Aleksey Shipilev wrote: > Hi Nezih, > > On 05.11.2014 22:33, Nezih Yigitbasi wrote: >> We are seeing a weird GC problem with the jol library with the >> ClassLayout.parseClass() call. The problem is that the calling >> thread spends a lot of time doing full GCs and it?s kind of stuck in >> a GC loop. We only observed this problem with the >> -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags >> where the explicit System.gc() call in the VMSupport.guessAlignment() >> method cause full GCs that are very slow (when these flags are >> removed I see less number of full GCs that are much faster and I >> don?t see the problem anymore). This seemed like a bug to me, but I >> just wanted to check with you to understand it better. > > Well, that code is running once during the initialization, and it does > indeed calls for GC to condense the newly allocated array with objects > to better estimate the alignment. > > I would agree that unexpected System.gc coming from a library is a > library bug, and therefore we can revisit this, filed: > https://bugs.openjdk.java.net/browse/CODETOOLS-7901085 Should be fixed now with: http://hg.openjdk.java.net/code-tools/jol/rev/c58aecad901f Can you confirm? -Aleksey. From nyigitbasi at netflix.com Wed Nov 5 20:52:12 2014 From: nyigitbasi at netflix.com (Nezih Yigitbasi) Date: Wed, 5 Nov 2014 12:52:12 -0800 Subject: problem with ClassLayout.parseClass In-Reply-To: <545A8B92.9030602@oracle.com> References: <545A8819.1030307@oracle.com> <545A8B92.9030602@oracle.com> Message-ID: Yep the problem is fixed with your latest change. Thanks for the quick fix. When can you push a new release to the maven central repo? On Wed, Nov 5, 2014 at 12:41 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 05.11.2014 23:27, Aleksey Shipilev wrote: > > Hi Nezih, > > > > On 05.11.2014 22:33, Nezih Yigitbasi wrote: > >> We are seeing a weird GC problem with the jol library with the > >> ClassLayout.parseClass() call. The problem is that the calling > >> thread spends a lot of time doing full GCs and it?s kind of stuck in > >> a GC loop. We only observed this problem with the > >> -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags > >> where the explicit System.gc() call in the VMSupport.guessAlignment() > >> method cause full GCs that are very slow (when these flags are > >> removed I see less number of full GCs that are much faster and I > >> don?t see the problem anymore). This seemed like a bug to me, but I > >> just wanted to check with you to understand it better. > > > > Well, that code is running once during the initialization, and it does > > indeed calls for GC to condense the newly allocated array with objects > > to better estimate the alignment. > > > > I would agree that unexpected System.gc coming from a library is a > > library bug, and therefore we can revisit this, filed: > > https://bugs.openjdk.java.net/browse/CODETOOLS-7901085 > > Should be fixed now with: > http://hg.openjdk.java.net/code-tools/jol/rev/c58aecad901f > > Can you confirm? > > -Aleksey. > > From aleksey.shipilev at oracle.com Wed Nov 5 20:56:28 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Nov 2014 23:56:28 +0300 Subject: problem with ClassLayout.parseClass In-Reply-To: References: <545A8819.1030307@oracle.com> <545A8B92.9030602@oracle.com> Message-ID: <545A8EFC.2050200@oracle.com> Excellent. It has been a while since last release, might be this week. How important is this for you? -Aleksey. On 05.11.2014 23:52, Nezih Yigitbasi wrote: > Yep the problem is fixed with your latest change. Thanks for the quick > fix. When can you push a new release to the maven central repo? > > On Wed, Nov 5, 2014 at 12:41 PM, Aleksey Shipilev > > wrote: > > On 05.11.2014 23:27, Aleksey Shipilev wrote: > > Hi Nezih, > > > > On 05.11.2014 22:33, Nezih Yigitbasi wrote: > >> We are seeing a weird GC problem with the jol library with the > >> ClassLayout.parseClass() call. The problem is that the calling > >> thread spends a lot of time doing full GCs and it?s kind of stuck in > >> a GC loop. We only observed this problem with the > >> -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags > >> where the explicit System.gc() call in the VMSupport.guessAlignment() > >> method cause full GCs that are very slow (when these flags are > >> removed I see less number of full GCs that are much faster and I > >> don?t see the problem anymore). This seemed like a bug to me, but I > >> just wanted to check with you to understand it better. > > > > Well, that code is running once during the initialization, and it does > > indeed calls for GC to condense the newly allocated array with objects > > to better estimate the alignment. > > > > I would agree that unexpected System.gc coming from a library is a > > library bug, and therefore we can revisit this, filed: > > https://bugs.openjdk.java.net/browse/CODETOOLS-7901085 > > Should be fixed now with: > http://hg.openjdk.java.net/code-tools/jol/rev/c58aecad901f > > Can you confirm? > > -Aleksey. > > From nyigitbasi at netflix.com Wed Nov 5 20:57:52 2014 From: nyigitbasi at netflix.com (Nezih Yigitbasi) Date: Wed, 5 Nov 2014 12:57:52 -0800 Subject: problem with ClassLayout.parseClass In-Reply-To: <545A8EFC.2050200@oracle.com> References: <545A8819.1030307@oracle.com> <545A8B92.9030602@oracle.com> <545A8EFC.2050200@oracle.com> Message-ID: Not that urgent, a release this week or early next week would be awesome. On Wed, Nov 5, 2014 at 12:56 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > Excellent. It has been a while since last release, might be this week. > How important is this for you? > > -Aleksey. > > On 05.11.2014 23:52, Nezih Yigitbasi wrote: > > Yep the problem is fixed with your latest change. Thanks for the quick > > fix. When can you push a new release to the maven central repo? > > > > On Wed, Nov 5, 2014 at 12:41 PM, Aleksey Shipilev > > > > wrote: > > > > On 05.11.2014 23:27, Aleksey Shipilev wrote: > > > Hi Nezih, > > > > > > On 05.11.2014 22:33, Nezih Yigitbasi wrote: > > >> We are seeing a weird GC problem with the jol library with the > > >> ClassLayout.parseClass() call. The problem is that the calling > > >> thread spends a lot of time doing full GCs and it?s kind of stuck > in > > >> a GC loop. We only observed this problem with the > > >> -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags > > >> where the explicit System.gc() call in the > VMSupport.guessAlignment() > > >> method cause full GCs that are very slow (when these flags are > > >> removed I see less number of full GCs that are much faster and I > > >> don?t see the problem anymore). This seemed like a bug to me, but > I > > >> just wanted to check with you to understand it better. > > > > > > Well, that code is running once during the initialization, and it > does > > > indeed calls for GC to condense the newly allocated array with > objects > > > to better estimate the alignment. > > > > > > I would agree that unexpected System.gc coming from a library is a > > > library bug, and therefore we can revisit this, filed: > > > https://bugs.openjdk.java.net/browse/CODETOOLS-7901085 > > > > Should be fixed now with: > > http://hg.openjdk.java.net/code-tools/jol/rev/c58aecad901f > > > > Can you confirm? > > > > -Aleksey. > > > > > > > From aleksey.shipilev at oracle.com Fri Nov 7 14:35:35 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 07 Nov 2014 17:35:35 +0300 Subject: JOL 0.2 Message-ID: <545CD8B7.2050000@oracle.com> Hi, JOL 0.2 is released and available at Maven Central (thanks to Evgeny Mandrikov, as always!). This is a maintenance release, and it includes a few functional and performance fixes accumulated since 0.1, namely: * JRockit-specific compressed references detection code was not working properly in all cases: http://hg.openjdk.java.net/code-tools/jol/rev/4aa90b3ecb20 * JDK 9 had protected some system fields from setAccessible(true) calls, which throws unexpected exceptions. Luckily, we can also do a more robust way to introspect the class contents: https://bugs.openjdk.java.net/browse/CODETOOLS-7901068 http://hg.openjdk.java.net/code-tools/jol/rev/286e7f914795 * jol-estimates.jar output was garbled, due to refactoring overlook: http://hg.openjdk.java.net/code-tools/jol/rev/74fcfa26ecc4 * When object alignment information is not available, JOL tries to guess it with a simple experiment. 0.1 code was using System.gc() aggressively, which does not play out well when JOL is embedded as a library. 0.2 code does a simpler experiment: https://bugs.openjdk.java.net/browse/CODETOOLS-7901085 http://hg.openjdk.java.net/code-tools/jol/rev/c58aecad901f Enjoy! Thanks, -Aleksey. From aleksey.shipilev at oracle.com Fri Nov 7 14:37:35 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Fri, 07 Nov 2014 14:37:35 +0000 Subject: hg: code-tools/jol: 3 new changesets Message-ID: <201411071437.sA7EbZWu019318@aojmv0008> Changeset: a194a2d741c8 Author: shade Date: 2014-11-06 12:37 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/a194a2d741c8 JOL v0.2 ! jol-cli/pom.xml ! jol-core/pom.xml ! jol-samples/pom.xml ! pom.xml Changeset: e90e0b2d9893 Author: shade Date: 2014-11-06 12:38 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/e90e0b2d9893 Added tag 0.2 for changeset a194a2d741c8 ! .hgtags Changeset: d16d0a0e7591 Author: shade Date: 2014-11-06 12:38 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/d16d0a0e7591 Continue in 1.0-SNAPSHOT. ! jol-cli/pom.xml ! jol-core/pom.xml ! jol-samples/pom.xml ! pom.xml From aleksey.shipilev at oracle.com Mon Nov 24 20:03:02 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Mon, 24 Nov 2014 20:03:02 +0000 Subject: hg: code-tools/jol: 7901112: Provide the data model with a given object alignment Message-ID: <201411242003.sAOK32H2027597@aojmv0008> Changeset: e6d1987f0b13 Author: shade Date: 2014-11-24 23:02 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/e6d1987f0b13 7901112: Provide the data model with a given object alignment ! jol-cli/src/main/java/org/openjdk/jol/MainHeapDump.java ! jol-cli/src/main/java/org/openjdk/jol/MainObjectEstimates.java ! jol-core/src/main/java/org/openjdk/jol/datamodel/CurrentDataModel.java ! jol-core/src/main/java/org/openjdk/jol/datamodel/DataModel.java ! jol-core/src/main/java/org/openjdk/jol/datamodel/X86_32_DataModel.java ! jol-core/src/main/java/org/openjdk/jol/datamodel/X86_64_COOPS_DataModel.java ! jol-core/src/main/java/org/openjdk/jol/datamodel/X86_64_DataModel.java ! jol-core/src/main/java/org/openjdk/jol/layouters/CurrentLayouter.java ! jol-core/src/main/java/org/openjdk/jol/layouters/HotSpotLayouter.java ! jol-core/src/main/java/org/openjdk/jol/util/MathUtil.java ! jol-core/src/main/java/org/openjdk/jol/util/VMSupport.java From aleksey.shipilev at oracle.com Tue Nov 25 16:26:16 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Tue, 25 Nov 2014 16:26:16 +0000 Subject: hg: code-tools/jol: String Compression (JDK-8054307) estimators. Message-ID: <201411251626.sAPGQGdI016988@aojmv0008> Changeset: 55a410e7d227 Author: shade Date: 2014-11-25 19:24 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/55a410e7d227 String Compression (JDK-8054307) estimators. ! jol-cli/pom.xml + jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java From aleksey.shipilev at oracle.com Wed Nov 26 17:46:51 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Wed, 26 Nov 2014 17:46:51 +0000 Subject: hg: code-tools/jol: 4 new changesets Message-ID: <201411261746.sAQHkpZY022008@aojmv0008> Changeset: 668e312a1311 Author: shade Date: 2014-11-26 13:51 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/668e312a1311 Fixes for String compress estimation. ! jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java Changeset: 11adb4d06f2c Author: shade Date: 2014-11-26 15:13 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/11adb4d06f2c Parallel String compress estimation. ! jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java Changeset: b60b7bc24981 Author: shade Date: 2014-11-26 16:09 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/b60b7bc24981 String compress estimation should read the heap dump only once. ! jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java Changeset: 56dd7067ed0f Author: shade Date: 2014-11-26 20:46 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/56dd7067ed0f String compression should also estimate String size distribution. ! jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java From aleksey.shipilev at oracle.com Wed Nov 26 21:18:29 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Wed, 26 Nov 2014 21:18:29 +0000 Subject: hg: code-tools/jol: 7901114: JOL Samples should be BSD-licensed Message-ID: <201411262118.sAQLITcG003709@aojmv0008> Changeset: 4712045c0634 Author: shade Date: 2014-11-27 00:18 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/4712045c0634 7901114: JOL Samples should be BSD-licensed ! jol-samples/pom.xml ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_01_Basic.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_02_Alignment.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_03_Packing.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_04_Inheritance.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_05_InheritanceBarrier.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_06_Gaps.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_07_Exceptions.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_08_Class.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_09_Contended.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_10_DataModels.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_11_ClassWord.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_12_ThinLocking.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_13_BiasedLocking.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_14_FatLocking.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_15_IdentityHashCode.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_16_AL_LL.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_17_Allocation.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_18_Layouts.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_19_Promotion.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_20_Roots.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_21_Arrays.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_22_Compaction.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_23_Defragmentation.java ! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_24_Colocation.java ! jol-samples/src/main/java/sun/misc/Contended.java ! jol-samples/src/resources/LICENSE + src/license/bsd/header.txt + src/license/bsd/license.txt From aleksey.shipilev at oracle.com Thu Nov 27 18:15:49 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Thu, 27 Nov 2014 18:15:49 +0000 Subject: hg: code-tools/jol: 4 new changesets Message-ID: <201411271815.sARIFneT021552@aojmv0008> Changeset: ee279c92aa66 Author: shade Date: 2014-11-27 17:09 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/ee279c92aa66 String compression should be more robust in the face of broken heap dumps. ! jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java + jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpException.java ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java Changeset: 553184df3fe8 Author: shade Date: 2014-11-27 17:30 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/553184df3fe8 String compression should be resilient for integer overflows. ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java Changeset: ed7039f2e482 Author: shade Date: 2014-11-27 17:46 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/ed7039f2e482 String compression: performance optimizations ! jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java Changeset: 211423c55906 Author: shade Date: 2014-11-27 21:15 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/211423c55906 String compression: more improvements. ! jol-cli/src/main/java/org/openjdk/jol/MainStringCompress.java ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java From aleksey.shipilev at oracle.com Thu Nov 27 23:20:42 2014 From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com) Date: Thu, 27 Nov 2014 23:20:42 +0000 Subject: hg: code-tools/jol: String compression: accept gzip-compressed hprofs. Message-ID: <201411272320.sARNKgVF016685@aojmv0008> Changeset: 8547afa4d062 Author: shade Date: 2014-11-28 02:20 +0300 URL: http://hg.openjdk.java.net/code-tools/jol/rev/8547afa4d062 String compression: accept gzip-compressed hprofs. ! jol-core/src/main/java/org/openjdk/jol/heap/HeapDumpReader.java