On Tue, 26 Sep 2023 21:08:36 GMT, Coleen Phillimore wrote:
>> Afshin Zafari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> MetaspaceSize and its lower bound is used.
>
> This looks good to me.
Thank you @coleenp and @dholmes-ora for yo
On Tue, 26 Sep 2023 08:35:10 GMT, Afshin Zafari wrote:
>> 1. `ArrayAllocatorMallocLimit` is removed. The test cases that tested it
>> also are removed.
>> 2. `AllocArrayAllocator` instances are replaced with `MallocArrayAllocator`.
>> 3. The signature of `CHeapBitMap::free(ptr, size)` is kept as
On Tue, 26 Sep 2023 08:35:10 GMT, Afshin Zafari wrote:
>> 1. `ArrayAllocatorMallocLimit` is removed. The test cases that tested it
>> also are removed.
>> 2. `AllocArrayAllocator` instances are replaced with `MallocArrayAllocator`.
>> 3. The signature of `CHeapBitMap::free(ptr, size)` is kept as
> 1. `ArrayAllocatorMallocLimit` is removed. The test cases that tested it also
> are removed.
> 2. `AllocArrayAllocator` instances are replaced with `MallocArrayAllocator`.
> 3. The signature of `CHeapBitMap::free(ptr, size)` is kept as it is, since it
> is called in this way from `GrowableBitMa
On Thu, 12 Jan 2023 16:52:50 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.
On Thu, 12 Jan 2023 16:52:50 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.
On Wed, 11 Jan 2023 18:10:47 GMT, Justin King wrote:
> This leaves at least AIX as a potential problem. @backwaterred, does the AIX
> libc malloc() still exclusively use the data segment? Does free'd memory
> still stick to the process?
I agree with @coleenp that AIX seems to still use the dat
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
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 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 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 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
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 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 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
> 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
18 matches
Mail list logo
