On Wed, 22 Feb 2023 15:19:56 GMT, Justin King wrote:
>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use jvmtiDeallocate wrapper
>
> Signed-off-by: Justi
On Wed, 22 Feb 2023 14:26:08 GMT, Justin King wrote:
> Fix minor memory leaks in libjdwp.
This pull request has now been integrated.
Changeset: 2cf8b860
Author: Justin King
URL:
https://git.openjdk.org/jdk/commit/2cf8b8607dac961e1d63a905c6492daa54c944d5
Stats: 6 lines in 2 fi
On Wed, 22 Feb 2023 15:19:56 GMT, Justin King wrote:
>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use jvmtiDeallocate wrapper
>
> Signed-off-b
> Fix minor memory leaks in libjdwp.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Use jvmtiDeallocate wrapper
Signed-off-by: Justin King
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12716/files
-
Fix minor memory leaks in libjdwp.
-
Commit messages:
- Memory leaks in libjdwp
Changes: https://git.openjdk.org/jdk/pull/12716/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12716&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8303071
Stats: 6 lines in 2 files cha
On Tue, 7 Feb 2023 14:14:07 GMT, Justin King wrote:
> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags
> typically can be combined.
> - Update `MemoryType` to have enumeration names that follow the style guide,
> no `mt` prefix.
> - Create aliases
On Tue, 7 Feb 2023 14:43:01 GMT, Coleen Phillimore wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix refactor mistake
>>
>> Signed-off-by: Justin King
>
> I thin
tegy` and `AllocFailType` into
> `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective
> headers.
>
> This change does not update variable verbiage. That should be something done
> over time.
Justin King has updated the pull request incrementally wit
tegy` and `AllocFailType` into
> `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective
> headers.
>
> This change does not update variable verbiage. That should be something done
> over time.
Justin King has updated the pull request incrementally wit
On Tue, 7 Feb 2023 14:42:14 GMT, Coleen Phillimore wrote:
> I don't like MemoryType. MEMFLAGS makes it indicative that it's a flag for
> some purpose and sticks out to my eyes as a template parameter, which is part
> of our coding style. mtWhatever is easy to spot in the code where used. I
> d
tegy` and `AllocFailType` into
> `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective
> headers.
>
> This change does not update variable verbiage. That should be something done
> over time.
Justin King has updated the pull request incrementally wit
tegy` and `AllocFailType` into
> `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective
> headers.
>
> This change does not update variable verbiage. That should be something done
> over time.
Justin King has updated the pull request incrementally wit
- Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags
typically can be combined.
- Update `MemoryType` to have enumeration names that follow the style guide, no
`mt` prefix.
- Create aliases for old `mtXXX` names.
- Remove `mt_number_of_types` from the enumeration.
- Shift
On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote:
> Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time
> also fixing the serviceability code.
This pull request has now been integrated.
Changeset: 7c6a8db3
Author:Justin King
Committer: Tobias Hartman
On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote:
> Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time
> also fixing the serviceability code.
Cannot directly commit, so I will request integration and let prospective
sponsors do any additional testing
On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote:
> Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time
> also fixing the serviceability code.
Looks good this time.
-
PR: https://git.openjdk.org/jdk/pull/12345
Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also
fixing the serviceability code.
-
Commit messages:
- Redo removal of virtual methods in CodeHeap
Changes: https://git.openjdk.org/jdk/pull/12345/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=1
On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote:
> Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time
> also fixing the serviceability code.
Waiting on GHA to confirm if I fixed the serviceability code correctly.
-
PR: https://git.openjdk.org/jd
On Thu, 12 Jan 2023 07:32:24 GMT, Stefan Karlsson wrote:
> There's a FIXME about that allocation.inline.hpp file is now empty. Will you
> remove it in this patch? I'd prefer if you did. Alternatively, remove the
> FIXME from this patch and then immediately clean this up as a separate patch.
Ye
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit since the
On Fri, 13 Jan 2023 17:39:41 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
>>
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with two additional
commits si
On Wed, 11 Jan 2023 15:08:23 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
>>> o
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit si
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
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit since the
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit si
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
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
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit si
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
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit si
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit si
slower than going
> through `malloc` which can potentially re-use memory without making any
> system calls. The remaining usages of `ArrayAllocator` and
> `MallocArrayAllocator` are equivalent.
Justin King has updated the pull request incrementally with one additional
commit since the
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 going thr
35 matches
Mail list logo
