RFR: 8157023: Integrate NMT with JFR [v2]

Stefan Johansson sjohanss at openjdk.org
Mon Dec 5 13:47:56 UTC 2022


On Mon, 5 Dec 2022 13:26:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I can take a stab at it. Only thing I'm not clear about exactly what you mean is: we could hide the nitty gritty of result retrieving (e.g. mtNone, mtChunk handling etc) at least in part from using code like JFR.
> 
> Reporting is not always 1:1 wrt MEMFLAGS. Some are special:
> 
>     * mtNone should not really exist, and we want to remove it. StefanK did some preparatory work already. NMT reporter just prints an empty line, I think. I would just leave it out.
> 
Agree, should probably exclude that one.
>     * mtChunk is special because Arenas are in this weird role where they are arena memory, but then they are malloced. So reporting must report mtChunk allocations for chunks that belong to an arena under the arena's MEMFLAG. In my experiences, this breaks easily. But I see that is taken care of as part of the baseline() function (See MallocMemorySnapshot::make_adjustment()). So maybe you don't want to do anything here.
> 
I looked at that and decided to not dig into it, thanks for the explanation. 

> 
> But if you follow the breadcrumb of what MemReporter does, you should be fine.
> 
A very quick look at what your API could look like if I try to use the same style as currently used in NMT and creating something that works similar to `MemBaseline`. I ended up with:

struct VirtualMemoryPair {
  size_t reserved;
  size_t committed;
};

struct MemSnapshotOptions {
  bool include_malloc;
  bool include_vm;
  bool include_thread_stacks;
};

class MemSnapshot {
private:
  size_t _malloc_snapshot[mt_number_of_types];
  VirtualMemoryPair _vm_snapshot[mt_number_of_types];
  VirtualMemoryPair _thread_stack_snapshot;

  bool _has_malloc_snapshot;
  bool _has_vm_snapshot;
  bool _has_thread_stack_snapshot;

public:
  MemSnapshot(MemSnapshotOptions options);
  void snap();
};


So basically you create your `MemSnapshot` with a set of options and then "snap" it to update. Not sure if there is a use-case where one want a single snapshot but want to call it with different options. What do you think about this? 

If going with this approach I plan to add getters like:

size_t getReserved(MEMFLAGS);
size_t getCommitted(MEMFLAGS);

Not sure if it makes sense to have getters for the individual "snapshots", also not sure if one should assert that no one calls it using mtThreadStack/mtThread if that options is off. Or just report the cheap numbers.

> p.s. my peak display change is up for review, I would be happy if you could give it an eye? #11497

I'll try to find time tomorrow or later today.

-------------

PR: https://git.openjdk.org/jdk/pull/11449


More information about the hotspot-dev mailing list