RFR: 8219414: SA: jhsdb jsnap throws UnmappedAddressException with core generated by gcore
Yasumasa Suenaga
yasuenag at gmail.com
Thu Feb 21 02:02:37 UTC 2019
Hi Chris,
I grep'ed with "MAP_SHARED" on jdk/src.
Shared memory is used in ZGC (ZBackingFile and ZPhysicalMemoryBacking)
and in FileChannel::map at least.
I think we have memory footprint concern about them, but shared memory
should be dumped.
If we did not get them, we cannot analyze ZGC related behavior and
other code which uses shared memory.
(We can pass FD to os::reserve_memory - it will use shared memory if
FD is passed.)
Thus I want to introduce `DumpSharedMappingsInCore` for dumping shared
memory and set it to true by default.
Thanks,
Yasumasa
2019年2月21日(木) 3:10 Chris Plummer <chris.plummer at oracle.com>:
>
> [adding runtime]
>
> Hi Yasumasa,
>
> Overall looks good. Just a couple of questions.
>
> Do we have the same footprint concerns with the shared mappings as we
> did with the private mappings? If not, possibly it doesn't need an
> option and should always be enabled.
>
> thanks,
>
> Chris
>
> On 2/20/19 12:03 AM, Yasumasa Suenaga wrote:
> > Hi all,
> >
> > Please review this webrev:
> >
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8219414
> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219414/webrev.00/
> >
> > I tried to get PerfCounter values via `jhsdb jsnap` from core image
> > which is generated by `gcore` (provided by GDB), but I encountered
> > UnmappedAddressException.
> >
> > It is caused by `generate-core-file` on GDB regards `coredump_filter` on procfs.
> >
> > https://sourceware.org/gdb/onlinedocs/gdb/Core-File-Generation.html
> >
> > JDK-8200613 introduced `DumpPrivateMappingsInCore` for CDS. I want to
> > introduce `DumpSharedMappingsInCore` for shared memory mapping.
> >
> > Currently `DumpPrivateMappingsInCore` affects when `UseSharedSpaces` is enabled.
> > I want `DumpPrivateMappingsInCore` to affect independently in this
> > change because file-backed private memory which is not CDS might be
> > useful in the future.
> >
> >
> > Thanks,
> >
> > Yasumasa
>
>
More information about the serviceability-dev
mailing list