On Thu, 28 Jan 2021 07:36:44 GMT, Lin Zang wrote:
>> Hi Lin,
>> It is also in my memory that you actually did not have 4 arguments.
>> The real incompatibility issue was that the order of arguments was swapped.
>> It is why it was relatively easy to fall back and just update the constants
>> wit
On Thu, 28 Jan 2021 07:30:29 GMT, Serguei Spitsyn wrote:
>> Dear @plummercj，
>> You are right, the same issue has been encountered when I was developing
>> JDK-8215622. At that time the argument number does not actully exceed the
>> limitation (3), and so I made a quick fix to change back arg_c
On Thu, 28 Jan 2021 03:39:37 GMT, Lin Zang wrote:
>> It looks like
>> [JDK-8215622](https://bugs.openjdk.java.net/browse/JDK-8215622) introduced a
>> 4th argument to the attach API, and this caused hangs when and older JVMs
>> tried to attach. That was fixed by
>> [JDK-8219721](https://bugs.o
On Fri, 15 Jan 2021 07:07:30 GMT, Leonid Mesnik wrote:
> The test failed because it expects that public/protected/default/private and
> static modifiers differ on the JVM level like in Java source code. However,
> only the ACC_PUBLIC modifier has an effect on interfaces.
>
> Here is my proposa
On Wed, 27 Jan 2021 23:06:41 GMT, Kim Barrett wrote:
> Please review this change which merges ImmutableSpace into MutableSpace,
> eliminating the former. There were no interesting uses of ImmutableSpace,
> other than as the base class for MutableSpace. The name ImmutableSpace is
> kind of a mis
Hi Alex,
On 28/01/2021 7:44 am, Alex Menkov wrote:
On Tue, 19 Jan 2021 23:18:04 GMT, David Holmes wrote:
Alex Menkov has updated the pull request incrementally with one additional
commit since the last revision:
Non-lava launchers should process all "-J" arguments
Hi Alex,
I think thi
Hi Igor,
On 28/01/2021 2:46 am, Igor Veresov wrote:
On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov wrote:
Looks better now. I would like to see result of performance testing before
approving.
I asked Eric to run the benchmarks. The results should be ready on Wednesday.
The benchmarking i
On Wed, 27 Jan 2021 19:58:39 GMT, Chris Plummer wrote:
>>> This patch introduces a new "parallel" option to jmap, so after this patch,
>>> there can be at most 4 options for jmap that can be passed to JDK.
>>>
>>> The issue is that there is a limitation in old version of jmap that at most
>>>
On Wed, 27 Jan 2021 23:06:41 GMT, Kim Barrett wrote:
> Please review this change which merges ImmutableSpace into MutableSpace,
> eliminating the former. There were no interesting uses of ImmutableSpace,
> other than as the base class for MutableSpace. The name ImmutableSpace is
> kind of a mis
> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
Lin Zang has updated the pull request incrementally with one additional commit
since the last revision:
fix the logic of using gz= as file name
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1712/files
On Wed, 27 Jan 2021 20:22:00 GMT, Serguei Spitsyn wrote:
>>> Do you think it is reasonable to treat "gz=[number]/[non-number]"
>>> differently in this case? or should it just exit with error for all "gz="
>>> options that is not in the range of compression level? BTW, I think your
>>> suggeste
Please review this change which merges ImmutableSpace into MutableSpace,
eliminating the former. There were no interesting uses of ImmutableSpace,
other than as the base class for MutableSpace. The name ImmutableSpace is
kind of a misnomer given that usage.
Testing:
mach5 tier1-3
-
On Tue, 19 Jan 2021 23:18:04 GMT, David Holmes wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Non-lava launchers should process all "-J" arguments
>
> Hi Alex,
>
> I think this is functionally correct now - though
On Wed, 27 Jan 2021 14:17:22 GMT, Daniel D. Daugherty
wrote:
>>> I thought the comments regarding the test were to use an if statement to
>>> check iter.hasNext() and return after seeing one Monitor, rather than
>>> keeping the while-loop and reporting every single Monitor found. The latter
>
On Wed, 27 Jan 2021 18:58:01 GMT, Chris Plummer wrote:
> I think we should produce an error for something like gz=abc rather than use
> that as the filename, because I think it is likely user error.
Agreed. My suggestion was exactly this. We have to return an error in any
attempt to start filen
On Wed, 27 Jan 2021 19:21:35 GMT, Chris Plummer wrote:
>> Dear All,
>> I have made a draft patch on parallel heap dump of jmap.
>> This patch is still WIP with test case under development and code refining
>> is in process.
>>
>> But I want to firstly ask your help to discuss a potential com
On Wed, 27 Jan 2021 13:15:06 GMT, Lin Zang wrote:
> This patch introduces a new "parallel" option to jmap, so after this patch,
> there can be at most 4 options for jmap that can be passed to JDK.
>
> The issue is that there is a limitation in old version of jmap that at most 3
> arguments can
On Wed, 27 Jan 2021 10:36:54 GMT, Lin Zang wrote:
> Do you think it is reasonable to treat "gz=[number]/[non-number]" differently
> in this case? or should it just exit with error for all "gz=" options that is
> not in the range of compression level? BTW, I think your suggested code is
> bette
> This change removes the legacy compilation policy and an emulation mode to
> the tiered policy to simulate the old behavior with
> ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code,
> devirtualizes the compilation policy API, adds a consistent way to query
> compile
On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov wrote:
>> This change removes the legacy compilation policy and an emulation mode to
>> the tiered policy to simulate the old behavior with
>> ```-XX:-TieredCompilation```. The change removed a bunch of interpreter
>> code, devirtualizes the compi
On Wed, 27 Jan 2021 16:43:28 GMT, Igor Veresov wrote:
>> I asked Eric to run the benchmarks. The results should be ready on Wednesday.
>
> The benchmarking is done. No regressions. There are mild improvements in
> startup benchmarks on the order of 1-5% (I suspect because of the compilation
> p
On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov wrote:
>> Looks better now. I would like to see result of performance testing before
>> approving.
>
> I asked Eric to run the benchmarks. The results should be ready on Wednesday.
The benchmarking is done. No regressions. There are mild improvemen
On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie wrote:
> Build changes per se now looks okay. However, I agree with Erik that unless
> this PR can wait for the JNF removal, at the very least the build docs needs
> to be updated to explain how to successfully build for this platform. (I can
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
On Wed, 27 Jan 2021 05:41:47 GMT, Yasumasa Suenaga wrote:
>> Hi Yasumasa,
>>
>> I thought the comments regarding the test were to use an if statement to
>> check iter.hasNext() and return after seeing one Monitor, rather than
>> keeping the while-loop and reporting every single Monitor found.
On Wed, 27 Jan 2021 12:49:29 GMT, Lin Zang wrote:
> 8252842: Extend jmap to support parallel heap dump
Dear All,
I have made a draft patch on parallel heap dump of jmap.
This patch is still WIP with test case under development and code refining is
in process.
But I want to firstly ask your
On Wed, 27 Jan 2021 12:49:29 GMT, Lin Zang wrote:
> 8252842: Extend jmap to support parallel heap dump
src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java line 263:
> 261: // See AttachOperation::arg_count_max in attachListener.hpp for
> argument count limitation.
> 262: String
8252842: Extend jmap to support parallel heap dump
-
Commit messages:
- fix white space trailing issue
- 8252842: Extend jmap to support parallel heap dump
Changes: https://git.openjdk.java.net/jdk/pull/2261/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=00
On Tue, 26 Jan 2021 19:34:35 GMT, Claes Redestad wrote:
> Simplify and desugar the static initialization of PlatformMBeanFinder.
>
> While arguably making the code easier to comprehend, this saves 5-6ms on
> startup in various applications such as the spring-petclinic.
This pull request has n
On Tue, 26 Jan 2021 21:26:32 GMT, Mandy Chung wrote:
>> Simplify and desugar the static initialization of PlatformMBeanFinder.
>>
>> While arguably making the code easier to comprehend, this saves 5-6ms on
>> startup in various applications such as the spring-petclinic.
>
> Looks fine.
@mlchu
On Tue, 26 Jan 2021 19:34:35 GMT, Claes Redestad wrote:
> Simplify and desugar the static initialization of PlatformMBeanFinder.
>
> While arguably making the code easier to comprehend, this saves 5-6ms on
> startup in various applications such as the spring-petclinic.
LGTM - it's a bit sad t
> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
Lin Zang has updated the pull request incrementally with one additional commit
since the last revision:
fix code in CommandProcessor
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1712/files
- new: htt
On Tue, 26 Jan 2021 10:03:13 GMT, Serguei Spitsyn wrote:
>> Copyrights need updating.
>
> Minor suggestion for
> `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JMap.java`:
> +} else if (keyValue[0].equals("gz")) {
> +if (keyValue.le
On Tue, 26 Jan 2021 12:42:41 GMT, Lin Zang wrote:
> This is used to guard the case cntTokens == 0, otherwise that t.nextToken()
> will throw ArrayIndexOutOfBoundsException.
The line `String option = t.nextToken();` can be moved to each of two if
statements:
if (cntTokens == 2) {
On 1/26/21 6:42 PM, erik.joels...@oracle.com wrote:
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve
On 1/26/21 6:42 PM, erik.joels...@oracle.com wrote:
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will so
> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
Lin Zang has updated the pull request incrementally with one additional commit
since the last revision:
fix issue cause JMapHProfLargeHeapTest fail and code refine
-
Changes:
- all: https://git.openjdk.java.net/j
I don't know why the Skara tools decided to associate my comment with
Alan Hayward's comment as they are not at all related. :(
David
On 27/01/2021 4:50 pm, David Holmes wrote:
On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward
wrote:
AIUI, the configure line needs passing a prebuilt JavaNativ
On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik wrote:
>> make/autoconf/build-aux/autoconf-config.guess line 1275:
>>
>>> 1273: UNAME_PROCESSOR="aarch64"
>>> 1274: fi
>>> 1275: fi ;;
>>
>> Almost, but not quite, correct. We cannot change the a
On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster
wrote:
>> @luhenry , could you please check this comment, I think SA-agent was MS's
>> job here.
>
> The target is identified by the header file now:
> https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083
On Fri, 22 Jan 2021 17:44:34 GMT, Vladimir Kozlov wrote:
>> Roland Westrelin has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains seven additional
>>
On Wed, 27 Jan 2021 08:07:04 GMT, Roland Westrelin wrote:
>> I noticed that the SA's dumpreplaydata command fails with:
>>
>> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file,
>> please wait...
>> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata do
On Wed, 27 Jan 2021 08:14:43 GMT, Chris Plummer wrote:
>> Roland Westrelin has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains seven additional
>> c
On Mon, 25 Jan 2021 19:43:56 GMT, Chris Plummer wrote:
>> Roland Westrelin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> use CoreUtils
>
> test/lib/jdk/test/lib/util/CoreUtils.java line 193:
>
>> 191: public static String getCoreF
> I noticed that the SA's dumpreplaydata command fails with:
>
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file,
> please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not
> appear to be polymorphic
>
> with a simple test progra
46 matches
Mail list logo
