Hi Alan, Peter, The main bit of data I wanted out of this was the sum total of native memory being used to store DirectByteBuffers, and to have that information printed in diagnostic cores.
Thanks for pointing out Bits. I will investigate if there is a way to make that data available to the VM when a diagnostic core is generated (I'm poking through SharedSecrets and JavaNioAccess now) without running java code. Worst case scenario, we don't get this feature, and at least we can retrieve this information from the core by using, as Alan suggests, an SA- based tool to retrieve the state of the Bits variables at crash-time. Best Regards Adam Farley From: Alan Bateman <alan.bate...@oracle.com> To: Peter Levart <peter.lev...@gmail.com>, Adam Farley8 <adam.far...@uk.ibm.com> Cc: "hotspot-...@openjdk.java.net developers" <hotspot-...@openjdk.java.net>, core-libs-dev <core-libs-dev@openjdk.java.net> Date: 23/02/2018 17:52 Subject: Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers On 23/02/2018 15:28, Peter Levart wrote: > Hi Adam, > > Did you know that native memory is already tracked on the Java side for > direct ByteBuffers? See class java.nio.Bits. Could you make use of it? > Right, these are the fields that are exposed at runtime via BufferPoolMXBean. A SA based tool could read from a core file. I can't tell if this is enough for Adam, it may be that the his tool reveals more details on the buffers in the pools. -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU