On Wed, 1 Nov 2023 10:04:30 GMT, Johan Sjölen wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> OK, went through the cache. Will continue later.
> @jdksjolen anything more needed from my
On Wed, 1 Nov 2023 10:04:30 GMT, Johan Sjölen wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> OK, went through the cache. Will continue later.
@jdksjolen anything more needed from my side?
On Thu, 2 Nov 2023 15:25:14 GMT, Brice Dutheil wrote:
>> This prints protection and offset. The former is interesting for obvious
>> reasons (e.g. lets you tell apart stack guard regions from stack, or
>> uncommitted from committed regions) and the latter interesting for some
>> corner cases
On Wed, 1 Nov 2023 06:26:57 GMT, Thomas Stuefe wrote:
>> src/hotspot/os/linux/memMapPrinter_linux.cpp line 59:
>>
>>> 57: void print_OS_specific_details(outputStream* st) const override {
>>> 58: st->print("%s %s ", _info.prot, _info.offset);
>>> 59: }
>>
>> If that's all this is
On Wed, 1 Nov 2023 10:04:04 GMT, Johan Sjölen wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> src/hotspot/share/nmt/memMapPrinter.cpp line 119:
>
>> 117: assert(_capacity > _count,
On Wed, 1 Nov 2023 10:46:21 GMT, Johan Sjölen wrote:
>> Yes, it resulted in a significant performance gain for a test run where I
>> interleaved non-committed and committed memory of the same tag. I may have
>> been mistaken, of course.
>
> It being committed or reserved shouldn't matter (I
On Wed, 1 Nov 2023 10:13:03 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/nmt/memMapPrinter.cpp line 105:
>>
>>> 103: _ranges[_count - 1].to = to;
>>> 104: return true;
>>> 105: }
>>
>> I'm pretty sure that the virtual memory tracker already gives you the
>> minimal set of
On Wed, 1 Nov 2023 10:01:43 GMT, Johan Sjölen wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> src/hotspot/share/nmt/memMapPrinter.cpp line 105:
>
>> 103: _ranges[_count - 1].to = to;
On Wed, 1 Nov 2023 09:52:24 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/nmt/memMapPrinter.cpp line 99:
>>
>>> 97: }
>>> 98:
>>> 99: bool add(const void* from, const void* to, MEMFLAGS f) {
>>
>> Please mention that we're `add`ing in sorted order, that is that `forall R
>> \in _ranges:
On Sat, 28 Oct 2023 13:04:05 GMT, Thomas Stuefe wrote:
>> Analysts and supporters often use /proc/xx/maps to make sense of the memory
>> footprint of a process.
>>
>> Interpreting the memory map correctly can help when used as a complement to
>> other tools (e.g. NMT). There even exist tools
On Wed, 1 Nov 2023 09:48:39 GMT, Johan Sjölen wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> src/hotspot/share/nmt/memMapPrinter.cpp line 99:
>
>> 97: }
>> 98:
>> 99: bool add(const
On Sat, 28 Oct 2023 13:04:05 GMT, Thomas Stuefe wrote:
>> Analysts and supporters often use /proc/xx/maps to make sense of the memory
>> footprint of a process.
>>
>> Interpreting the memory map correctly can help when used as a complement to
>> other tools (e.g. NMT). There even exist tools
On Wed, 1 Nov 2023 07:32:23 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/nmt/memMapPrinter.cpp line 79:
>>
>>> 77: const void* const min = MAX2(from1, from2);
>>> 78: const void* const max = MIN2(to1, to2);
>>> 79: return min < max;
>>
>> I had to rewrite it as:
>>
>> `return
On Wed, 1 Nov 2023 09:37:22 GMT, Johan Sjölen wrote:
>> I'll do the former, that is clearer I agree, but leave the latter out (I
>> assume with the macro you mean add it to globalDefenitions.hpp).
>>
>> I fear that a lot of bikeshedding and general discussions would start, and
>> to do it
On Tue, 31 Oct 2023 17:08:15 GMT, Gerard Ziemski wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> src/hotspot/share/nmt/memMapPrinter.cpp line 79:
>
>> 77: const void* const min =
On Tue, 31 Oct 2023 16:58:19 GMT, Gerard Ziemski wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> src/hotspot/os/linux/memMapPrinter_linux.cpp line 59:
>
>> 57: void
On Mon, 30 Oct 2023 17:31:30 GMT, Gerard Ziemski wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> src/hotspot/os/linux/memMapPrinter_linux.cpp line 83:
>
>> 81: char line[linesize];
>>
On Mon, 30 Oct 2023 10:29:56 GMT, Johan Sjölen wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix various builds
>
> src/hotspot/os/linux/memMapPrinter_linux.cpp line 80:
>
>> 78: FILE* f =
On Sat, 28 Oct 2023 13:04:05 GMT, Thomas Stuefe wrote:
>> Analysts and supporters often use /proc/xx/maps to make sense of the memory
>> footprint of a process.
>>
>> Interpreting the memory map correctly can help when used as a complement to
>> other tools (e.g. NMT). There even exist tools
On Sat, 28 Oct 2023 13:04:05 GMT, Thomas Stuefe wrote:
>> Analysts and supporters often use /proc/xx/maps to make sense of the memory
>> footprint of a process.
>>
>> Interpreting the memory map correctly can help when used as a complement to
>> other tools (e.g. NMT). There even exist tools
> Analysts and supporters often use /proc/xx/maps to make sense of the memory
> footprint of a process.
>
> Interpreting the memory map correctly can help when used as a complement to
> other tools (e.g. NMT). There even exist tools out there that attempt to
> annotate the process memory map
21 matches
Mail list logo
