> Implementation of relativized locals in interpreter frames for x86. x64, arm,
> aarch64, ppc64le and riscv.
> Not relativized locals on zero and s390 but done some changes to cope with
> the changed generic code.
> Tested tier1-tier8 on supported platforms. The rest was sanity tested using
> Q
On Tue, 10 Jan 2023 23:36:37 GMT, Coleen Phillimore wrote:
>> Afshin Zafari has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
>> - 8292741: Convert JvmtiTagMapTable to ResourceHas
The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is
too restrictive.
javax.management.Attribute and AttributeList classes are also needed, and Query
related classes.
There are a number of Query-relate classes, so adding javax.management.* is
appropriate otherwise the
On Tue, 10 Jan 2023 22:50:11 GMT, Justin King wrote:
>> Remove abstraction that is a holdover from Solaris. Direct usages of
>> `MmapArrayAllocator` have been switched to normal `malloc`. The
>> justification is that none of the code paths are called from signal
>> handlers, so using `mmap` di
On Tue, 10 Jan 2023 12:57:18 GMT, Albert Mingkun Yang wrote:
>> Simple change of using the actual type for a field.
>>
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> review
Thanks for the revie
On Fri, 6 Jan 2023 14:13:05 GMT, Coleen Phillimore wrote:
>> The issue is not the underlying RHT methods but the semantics of the
>> `jvmtiTagMap` methods. If a call to add always expects to add then it should
>> be a fatal error if it actually did an update as that indicates something is
>> b
On Tue, 10 Jan 2023 10:51:14 GMT, Albert Mingkun Yang wrote:
> Simple change of using the actual type for a field.
>
> Test: hotspot_gc
This pull request has now been integrated.
Changeset: 5a9490a4
Author:Albert Mingkun Yang
URL:
https://git.openjdk.org/jdk/commit/5a9490a40e0fe281
> test of tier1-5 passed.
Afshin Zafari has updated the pull request incrementally with one additional
commit since the last revision:
8292741: Convert JvmtiTagMapTable to ResourceHashtable
-
Changes:
- all: https://git.openjdk.org/jdk/pull/11288/files
- new: https://git.open
> test of tier1-5 passed.
Afshin Zafari has updated the pull request incrementally with one additional
commit since the last revision:
8292741: Convert JvmtiTagMapTable to ResourceHashtable
-
Changes:
- all: https://git.openjdk.org/jdk/pull/11288/files
- new: https://git.open
> Please find a patch to improve JMX Repository.query performance
>
> Using ObjectName.apply() allows significantly decrease memory usage and the
> number of GC cycles:
> Before:
>
> $ java test 100 100
> Test PASSED in 8943169791 ns.
> GC: G1 Young Generation getCollectionCount()=177 ge
On Tue, 10 Jan 2023 17:14:29 GMT, Daniel Fuchs wrote:
> I see several issues with the proposed changes: ObjectName is not final, so
> I'm not sure the changes proposed to ObjectName are safe when/if a subclass
> is supplied. And in addition, because it's not final, you will need to make a
> de
On Wed, 11 Jan 2023 11:29:39 GMT, Alexey Bakhtin wrote:
>> Please find a patch to improve JMX Repository.query performance
>>
>> Using ObjectName.apply() allows significantly decrease memory usage and the
>> number of GC cycles:
>> Before:
>>
>> $ java test 100 100
>> Test PASSED in 89
On Wed, 11 Jan 2023 09:40:11 GMT, Kevin Walls wrote:
> The default setting for the ObjectInputFilter for JMX, introduced in jdk20,
> is too restrictive.
> javax.management.Attribute and AttributeList classes are also needed, and
> Query related classes.
>
> There are a number of Query-relate c
> Please find a patch to improve JMX Repository.query performance
>
> Using ObjectName.apply() allows significantly decrease memory usage and the
> number of GC cycles:
> Before:
>
> $ java test 100 100
> Test PASSED in 8943169791 ns.
> GC: G1 Young Generation getCollectionCount()=177 ge
On Wed, 11 Jan 2023 12:02:57 GMT, Daniel Fuchs wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use copy of the ObjectName for matching
>
> src/java.management/share/classes/javax/management/ObjectName.java line 2
On Wed, 11 Jan 2023 00:22:03 GMT, Archie L. Cobbs wrote:
>> So, if the code was be like this:
>>
>>
>> ThisEscapeLoop ref11 = this;
>> ThisEscapeLoop ref12 = null;
>> ThisEscapeLoop ref13 = null;
>> ThisEscapeLoop ref14 = null;
>> for (int i = 0; i < 100; i++) {
>> ref14 = ref13;
>> ref
On Wed, 11 Jan 2023 10:05:33 GMT, Stefan Karlsson wrote:
> I'm happy to see this flag getting removed. I'm less happy about seeing
> usages of the array allocators being replaced by macros. I'd rather see an
> effort towards getting rid of these macros. Could we limit this patch to only
> remo
On Tue, 10 Jan 2023 22:50:11 GMT, Justin King wrote:
>> Remove abstraction that is a holdover from Solaris. Direct usages of
>> `MmapArrayAllocator` have been switched to normal `malloc`. The
>> justification is that none of the code paths are called from signal
>> handlers, so using `mmap` di
On Wed, 11 Jan 2023 14:27:44 GMT, Justin King wrote:
> ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively
> MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and
> MmapArrayAllocator thus update references to ArrayAllocator to be
> MallocArrayAllocator?
Y
On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is gene
On Wed, 11 Jan 2023 14:12:46 GMT, Maurizio Cimadamore
wrote:
>> Actually I think it would take 1 + 1 + 3 iterations.
>>
>> During the first two iterations of the outer loop, nothing changes after the
>> first go round of the inner loop - i.e., the total set of possible
>> references in existe
> Remove abstraction that is a holdover from Solaris. Direct usages of
> `MmapArrayAllocator` have been switched to normal `malloc`. The justification
> is that none of the code paths are called from signal handlers, so using
> `mmap` directly does not make sense and is potentially slower than g
On Wed, 11 Jan 2023 15:08:23 GMT, Stefan Karlsson wrote:
> > ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively
> > MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and
> > MmapArrayAllocator thus update references to ArrayAllocator to be
> > MallocArrayA
On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote:
> Curious, I always thought we do ArrayAllocator - using mmap for larger
> allocations - to prevent memory retention for libc variants whose allocators
> are "grabby", i.e. which don't promptly return memory to the OS on free().
> E.g. bec
> Remove abstraction that is a holdover from Solaris. Direct usages of
> `MmapArrayAllocator` have been switched to normal `malloc`. The justification
> is that none of the code paths are called from signal handlers, so using
> `mmap` directly does not make sense and is potentially slower than g
On Wed, 11 Jan 2023 16:14:24 GMT, Maurizio Cimadamore
wrote:
>> True - probably 3 * 3 can be achieved if this:
>>
>>
>> ThisEscapeLoop ref21 = ref14;
>>
>> Is replaced with
>>
>>
>> ThisEscapeLoop ref21 = this;
>>
>>
>> In which case the inner loop won't converge immediately (a
On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Initialize memory to zero in zGranuleMap
>>
>> Signed-off-by: Justin King
>
> Curious, I always thought we do Arr
On Wed, 11 Jan 2023 18:44:20 GMT, Archie L. Cobbs wrote:
>> Also, looking at the loop test more closely, it seems to me that what the
>> compiler needs to do is to prove that there can be possible paths by which a
>> `this` can land into ref4.
>>
>> If we build a graph of all the assignments,
On Tue, 10 Jan 2023 10:49:52 GMT, Yi Yang wrote:
>> harmless refactor to share code across different platforms of
>> VirtualMachineImpl:
>> 1. Shared code to process command response after requesting a command
>> execution
>> 2. Read functionality in SocketInputStream can be reused
>
> Yi Yang
On Wed, 11 Jan 2023 15:59:29 GMT, Maurizio Cimadamore
wrote:
> What I'm interested in though is what incremental improvement is brought by
> the more complex analysis you have in this PR?
It's a good question. Here are some thoughts...
One meta-goal is that this analysis be conservative. In o
On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is gene
> Remove abstraction that is a holdover from Solaris. Direct usages of
> `MmapArrayAllocator` have been switched to normal `malloc`. The justification
> is that none of the code paths are called from signal handlers, so using
> `mmap` directly does not make sense and is potentially slower than g
On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Initialize memory to zero in zGranuleMap
>>
>> Signed-off-by: Justin King
>
> Curious, I always thought we do Arr
The sprintf is deprecated in Xcode 14 because of security concerns. The issue
was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for
hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)
for building, but the test case was not covered. The failure
On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote:
> The sprintf is deprecated in Xcode 14 because of security concerns. The issue
> was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)
> for hotspot impl, and
> [JDK-8299378](https://bugs.openjdk.org/browse/JDK-
On Wed, 11 Jan 2023 21:16:51 GMT, Mikael Vidstedt wrote:
> This PR does not address all the remaining sprintf:s in hotspot, and with it
> now explicitly forbidden the build will fail:
>
This is a question to me as well. I noticed there are still some use of
sprintf, but the building passed o
On Wed, 11 Jan 2023 19:10:04 GMT, Archie L. Cobbs wrote:
>> Good idea. Looks like the difference is in the noise, at least on my Macbook:
>>
>> Builds of master (jdk-21+3-69-gc6588d5bb3f)
>> ==
>>
>> Build times:
>>
>> real 2m24.650s
>> user 13m4
On Wed, 11 Jan 2023 21:45:20 GMT, Maurizio Cimadamore
wrote:
>> Regarding the assignment graph approach, I think that would work if the
>> references are bouncing around strictly between variables, but what if the
>> chain includes any of the more complicated stuff that is currently being
>>
On Tue, 10 Jan 2023 14:47:45 GMT, Fredrik Bredberg wrote:
>> src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
>>
>> Note, you changed the initial year. Should be:
>>
>> - * Copyri
On Wed, 11 Jan 2023 21:51:45 GMT, Maurizio Cimadamore
wrote:
> So, in this example though you are calling an instance method before the
> object is initialized, which would seem to me like a leak
D'oh, you're right. But if you made `returnMe()` static or private then the
argument would still
CC-ing serviceability.
Hi Yi,
In general, I think it's good to have tools for understanding the
internal layout of the class metadata layouts.
I think there are overlaps between your proposal and existing tools. For
example, there are jcmd options such as VM.class_hierarchy and
VM.classes,
On Wed, 11 Jan 2023 22:40:43 GMT, Archie L. Cobbs wrote:
>
> D'oh, you're right. But if you made `returnMe()` static or private then the
> argument would still hold.
>
> > And, if the method is static, same story - you are passing ref3 somewhere
> > else, and ref3 potentially contains this.
>
On Thu, 12 Jan 2023 00:15:08 GMT, Maurizio Cimadamore
wrote:
> So, for static methods, it could go down two ways: either we don't even look
> at referenced method bodies, give up and just declare "sorry, escaping". Or,
> if we look into method bodies, and see that the relationship between inne
`VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object)` is not
used. Furthermore it confuses the reader that runs across
`removeObjectMirror()` calls, because what is actually being called is
`removeObjectMirror(SoftObjectReference ref)`.
-
Commit messages:
- Remove ex
Hi Ioi,
> I think there are overlaps between your proposal and existing tools. For
> example, there are jcmd options such as VM.class_hierarchy and VM.classes,
> etc.
> The Serviceability Agent can also be used to analyze the contents of the
> class metadata.
Of course, we can continue to add jc
On 1/11/2023 6:52 PM, Yi Yang wrote:
Hi Ioi,
> I think there are overlaps between your proposal and existing tools. For
example, there are jcmd options such as VM.class_hierarchy and
VM.classes, etc.
> The Serviceability Agent can also be used to analyze the contents of
the class metadata.
On Wed, 11 Jan 2023 21:29:01 GMT, Xue-Lei Andrew Fan wrote:
> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) -
> > are your builds including C2? If so, why are you not running into the issue
> > for those files?
>
> I'm new to hotspot. Do you know how could I enable C
On Wed, 11 Jan 2023 20:53:38 GMT, Justin King wrote:
>> Remove abstraction that is a holdover from Solaris. Direct usages of
>> `MmapArrayAllocator` have been switched to normal `malloc`. The
>> justification is that none of the code paths are called from signal
>> handlers, so using `mmap` di
48 matches
Mail list logo
