Re: Proposal: track zlib native memory usage with NMTThomas Stüfe thomas.stuefe at gmail.com

[Thomas Stüfe]

I always meant to ask, why is it that we chose to dedicate the beginning of
> the memory chunk to NMT, and not the end?
>
> If we used the end, then in this case with an unbalanced malloc/free, we
> would still be OK.
>
> The end seems more natural to me and either way we need to track the size,
> and moreover, in the current case, we need the size of the header as well.
>
>
Can't use the end, since you don't know the size of the block in free(). If
you had the size, you wouldn't need the malloc header in the first place,
since its main purpose, apart from accounting tags, is to give you the size.

Cheers, Thomas


>
> cheers
>
> >
> > (Side note: our internal tracker sidesteps this problem entirely by
> > avoiding malloc headers. Instead, it uses a hash tables to match pointers
> > with their meta information. But that has other cons and I do not plan to
> > change the way NMT works.)
> >
> > Performance-wise, instead of calling into the libc directly, we would
> call
> > into the hotspot, then into the libc. That indirection will cost some
> > cycles. If NMT is off, there does not happen much more beside the real
> > malloc call. Even NMT summary mode is very cheap. So I don't expect this
> to
> > be a problem but will run performance tests.
> >
> > --------
> >
> > My patch [1] works and can be built and tested. But the PR is still a
> work
> > in progress. I just wanted to make sure nobody generally objects to my
> work.
> >
> > Cheers, Thomas
> >
> > [1] https://github.com/openjdk/jdk/pull/10988
> > [2] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer
> > [3]
> https://mail.openjdk.org/pipermail/hotspot-dev/2018-November/035358.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230323/4a300707/attachment-0001.htm>