NMT merges adjacent unrelated reservations

[Zhengyu Gu]

Hi Thomas,

My bad. NMT does track individual reservation separately, but it merges 
reservations during reporting ...

hotspot/src/share/vm/services/memBaseline.cpp #274

       // consolidate reserved memory regions for virtual memory map.
       // The criteria for consolidation is:
       // 1. two adjacent reserved memory regions
       // 2. belong to the same memory type
       // 3. reserved from the same callsite

If it is undesirable, could you please file a bug.

>> NMT depends on stack walking for caller, but it is not reliable, since
>> different compilers have different inline strategies ... due to memory
> That's fine, I could live with that :)
>
>> consumption concern, NMT only records one pc.
> Often, during debugging or analysis memory is not that much of a
> concern. There may be other situations where it is.
>>> Is there a way to add a tag to allocations for grouping purposes in the
>>> summary? Currently, given that there is only a single stack level in the
>>> source in the summary, it is very hard to assign allocations to the
>>> components that actually did the allocation.
>> Again, this is memory consumption concern. However, it is possible to
>> add new tracking categories, but you have to go through source code to130
>> change the tags.
> That I would not mind. Could I just add a few new categories? I saw that
> the tag is just a short, where half of it is already reserved.
Sure, you can. Check out enum MemoryType in 
src/share/vm/memory/allocation.hpp, we still have 162 types available.

Add your new type there and change memory tags in source code. There is 
one more place you need to update

src/share/vm/services/memBaseline.cpp Line #29



>
> (Looking at the use of MEMFLAGS variables, I think due to member
> alignment and padding it wouldn't matter even if you used a size_t btw).
>
>>> For some reasons the "for
>>> <component>" string is also missing in the malloc allocation map.
>> This may be related to the issue I mentioned above. You may also see
>> missing callers on Solaris, that is due to the memory allocations occur
>> before stacks are walkable.
> Using Linux here.
>
> I meant e.g. the line
>
> [0x00007fc1ae95f8c8] G1CollectorPolicy::G1CollectorPolicy()+0x978
>                              (malloc=1KB #1)
>
> in the details. While here it is easily possible to see that this is
> from the GC from the available stack contents, there are cases where
> this is not as easy. I saw that all allocations are now tagged with the
> originating component anyway, so an additional "for GC" like in the
> virtual memory map would help a lot.
Make sense in some cases, but for some utility functions, they may 
allocate memory for different categories, ReservedSpace is an example.

Thanks,

-Zhengyu


> Thanks,
>    Thomas
>