Re: RFR: Here are some URLClassPath patches

[mandy chung]

On 2/27/18 9:03 PM, Martin Buchholz wrote:

8198808: jdi tests failing after JDK-8198484
http://cr.openjdk.java.net/~martin/webrevs/jdk/jdi-ProblemList/ 


https://bugs.openjdk.java.net/browse/JDK-8198808


+1

Mandy

Re: RFR: Here are some URLClassPath patches

[David Holmes]

Looks good.

Thanks,
David

On 28/02/2018 3:03 PM, Martin Buchholz wrote:

8198808: jdi tests failing after JDK-8198484
http://cr.openjdk.java.net/~martin/webrevs/jdk/jdi-ProblemList/
https://bugs.openjdk.java.net/browse/JDK-8198808

Re: RFR: Here are some URLClassPath patches

[Martin Buchholz]

8198808: jdi tests failing after JDK-8198484
http://cr.openjdk.java.net/~martin/webrevs/jdk/jdi-ProblemList/
https://bugs.openjdk.java.net/browse/JDK-8198808

Re: RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

[David Holmes]

On 28/02/2018 7:17 AM, Igor Ignatyev wrote:

Hi David,

I have set Xmx equal to Xms, the test passes w/ different externally 
passed combinations of Xmx, Xms and UseCompressedOops.


http://cr.openjdk.java.net/~iignatyev//8190679/webrev.01/index.html


Looks good!

Thanks,
David


Thanks,
-- Igor

On Feb 26, 2018, at 9:00 PM, David Holmes > wrote:


Hi Igor,

On 27/02/2018 11:25 AM, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html

9 lines changed: 2 ins; 0 del; 7 mod;

Hi all,
could you please review the patch for TimSortStackSize2 test?
the test failed when externally passed (via -javaoption or -vmoption) 
-Xmx value is less than 770m or 385m, depending on UseCompressedOops. 
it happened because the test explicitly set Xms value, but didn't set 
Xmx.

now, the test sets Xmx as Xms times 2.


I'm not happy with setting Xmx at 2 times Xms - that seems to be 
setting ourselves up for another case where we can't set -Xmx at 
startup. This test has encountered problems in the past with external 
flag settings - see in particular the review thread for JDK-8075071:


http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032316.html

Will the test pass if we simply set -Xmx and -Xms to the same? Or 
(equivalently based on on previous review discussions) just set -Xmx 
instead of -Xms?


Thanks,
David

PS as it mostly affects hotspot testing, the patch will be pushed to 
jdk/hs.
webrev: 
http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
testing: java/util/Arrays/TimSortStackSize2.java  w/ and w/o 
externally provided Xmx value

JBS: https://bugs.openjdk.java.net/browse/JDK-8190679
Thanks,
-- Igor

Re: RFR: Here are some URLClassPath patches

[Joseph D. Darcy]

Hi Martin,

Until we figure out the best course of action, please problem list the 
failing test.


Thanks,

-Joe

On 2/27/2018 7:02 PM, Martin Buchholz wrote:

I should probably do more testing than usual when touching classloading...

We have a jdi test that does this (hg blame finds duke as only author):

 public static ClassLoader classLoaderValue;
 {
 try {
 urls[0] = new URL("hi there");
 } catch (java.net.MalformedURLException ee) {
 }
 classLoaderValue = new URLClassLoader(urls);
 }

The assignment to urls[0] never succeeds (!), so URLClassLoader(URL[]) is
called with an array holding a null.  Which should cause a NPE, but did not
prior to JDK-8198484 .
ArrayDeque does not permit null elements!

Should we accept the NPE as a bug fix and file a retroactive CSR for that,
or should we continue to compatibly tolerate null URLs (yuk)?

Can we get jdi team to fix their dodgy tests?

Re: RFR: Here are some URLClassPath patches

[David Holmes]

Hi Martin,

On 28/02/2018 1:02 PM, Martin Buchholz wrote:

I should probably do more testing than usual when touching classloading...

We have a jdi test that does this (hg blame finds duke as only author):

     public static ClassLoader classLoaderValue;
     {
         try {
             urls[0] = new URL("hi there");
         } catch (java.net.MalformedURLException ee) {
         }
         classLoaderValue = new URLClassLoader(urls);
     }

The assignment to urls[0] never succeeds (!), so URLClassLoader(URL[]) 
is called with an array holding a null.  Which should cause a NPE, but 
did not prior to JDK-8198484 
.

ArrayDeque does not permit null elements!

Should we accept the NPE as a bug fix and file a retroactive CSR for 
that, or should we continue to compatibly tolerate null URLs (yuk)?


As I wrote in the bug report the tolerance for nulls is very limited. 
Seems you can have them in the initial URL[] but if you actually try to 
use one you get NPE. So accepting a null entry in the URL[] seems rather 
pointless - and addURL explicitly states that null is ignored. So I'd 
argue for the CSR so we can at least consider whether we need tolerate this.



Can we get jdi team to fix their dodgy tests?


Yes. Depending on which way we go we may need a new bug, otherwise this 
one can be assigned back to hotspot->svc. I'm also perplexed by the test 
logic.


Thanks,
David

Re: RFR: Here are some URLClassPath patches

[Martin Buchholz]

I should probably do more testing than usual when touching classloading...

We have a jdi test that does this (hg blame finds duke as only author):

public static ClassLoader classLoaderValue;
{
try {
urls[0] = new URL("hi there");
} catch (java.net.MalformedURLException ee) {
}
classLoaderValue = new URLClassLoader(urls);
}

The assignment to urls[0] never succeeds (!), so URLClassLoader(URL[]) is
called with an array holding a null.  Which should cause a NPE, but did not
prior to JDK-8198484 .
ArrayDeque does not permit null elements!

Should we accept the NPE as a bug fix and file a retroactive CSR for that,
or should we continue to compatibly tolerate null URLs (yuk)?

Can we get jdi team to fix their dodgy tests?

Re: [JDK 11] RFR 8196759: Move two java/text/Normalizer tests into OpenJDK

[Chris Yin]

Thank you, Naoto

Regards,
Chris

> On 28 Feb 2018, at 2:39 AM, Naoto Sato  wrote:
> 
> Looks good.
> 
> Naoto
> 
> On 2/26/18 10:51 PM, Chris Yin wrote:
>> Please review the changes to move two java/text/Normalizer tests to OpenJDK 
>> jdk_text group, thanks
>> bug: https://bugs.openjdk.java.net/browse/JDK-8196759 
>> 
>> webrev: http://cr.openjdk.java.net/~xiaofeya/8196759/webrev.00/ 
>> 
>> Regards,
>> Chris

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

[Joseph D. Darcy]

Hi Liam,

On 2/24/2018 5:14 PM, Liam Miller-Cushon wrote:

Hi, thanks for the comments.

The updated webrev is at: 
http://cr.openjdk.java.net/~cushon/7183985/webrev.02/ 



On Fri, Feb 23, 2018 at 4:29 PM, Joseph D. Darcy > wrote:


Objects implementing the AnnotatedElement interface are also
created in javac during annotation processing. As a secondary
concern, it would be good to be have behavior between both javac
and runtime annotations consistent when possible. (My own to-do
list includes at least once such alignment JDK-8164819: "Make
javac's toString() on annotation objects consistent with core
reflection".)


Do you have a pointer to where that happens? There's 
javax.lang.model.AnnotatedConstruct#getAnnotation, which isn't 
affected by this issue--it throws MirroredTypesExceptionProxy when 
accessing an annotation value that is an array of class literals, 
regardless of whether the elements' classes are missing. I'm not 
seeing implementations of AnnotatedElement in langtools.


Sorry, I misremembered the situation in javac. For annotation processing 
in javac, AnnotatedElement is not a factor, but the class


src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java

in javac does create annotation proxies, which is the same general 
technique used to create the annotation objects at runtime for core 
reflection.  These annotation objects in javac for javax.lang.model and 
annotation processing, do not follow the full contract of 
java.lang.reflect.AnnotatedElement. In particular, the annotations 
returned are not necessarily serializable. The intersection of methods 
on AnnotatedConstruct and AnnotatedElement is only a proper subset of 
the methods on AnnotatedElement; however, getAnnotation​(Class 
annotationClass) is in the intersection.



Even in javac we've moved away from test and directory names based
on bugid. I'd recommend incorporating these regression tests into
the existing tests in
test/jdk/java/lang/annotation/Missing


Thanks for the reminder, done.



I believe the new tests could reuse some of the existing types in 
test/jdk/java/lang/annotation/Missing. For example, the new 
MissingAnnotation.java is an alpha-rename of the existing Missing.java. 
If such sharing is not practical, then I'd recommend putting the new 
files into a subdirectory under underneath test/.../annotation/Missing 
(otherwise it will be confusing to edit these tests in the future since 
too many file names will start with "Missing".)


In MissingClassArrayElementTest.java:

  71 public static void main(String[] args) throws Exception {
  72 ClassArrayAnnotation[] outer = 
Test.class.getAnnotation(AnnotationAnnotation.class).value();
  73 // The second entry in the values array can be loaded 
successfully
  74 assertEquals(Arrays.toString(outer[1].value()), "[class 
java.lang.String]");


Something like

assertEquals(Arrays.equals(outer[1].value(), {String.class})

would be more robust against any future changes in Class.toString. 
Likewise for the analogous comparisons.



It would be worth verifying whether or not this change also covers
java.lang.reflect.Executable.getParameterAnnotations(), more
specifically the implementation of that method in Method and
Constructor. The method getParameterAnnotations() is much less
used than getAnnotations and the other methods on the
AnnotatedElement interface, but still part of the annotations feature.


Done.


Thanks.

Cheers,

-Joe

Re: RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

[Igor Ignatyev]

Hi David,

I have set Xmx equal to Xms, the test passes w/ different externally passed 
combinations of Xmx, Xms and UseCompressedOops.

http://cr.openjdk.java.net/~iignatyev//8190679/webrev.01/index.html 


Thanks,
-- Igor

> On Feb 26, 2018, at 9:00 PM, David Holmes  wrote:
> 
> Hi Igor,
> 
> On 27/02/2018 11:25 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
>>> 9 lines changed: 2 ins; 0 del; 7 mod;
>> Hi all,
>> could you please review the patch for TimSortStackSize2 test?
>> the test failed when externally passed (via -javaoption or -vmoption) -Xmx 
>> value is less than 770m or 385m, depending on UseCompressedOops. it happened 
>> because the test explicitly set Xms value, but didn't set Xmx.
>> now, the test sets Xmx as Xms times 2.
> 
> I'm not happy with setting Xmx at 2 times Xms - that seems to be setting 
> ourselves up for another case where we can't set -Xmx at startup. This test 
> has encountered problems in the past with external flag settings - see in 
> particular the review thread for JDK-8075071:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032316.html
> 
> Will the test pass if we simply set -Xmx and -Xms to the same? Or 
> (equivalently based on on previous review discussions) just set -Xmx instead 
> of -Xms?
> 
> Thanks,
> David
> 
>> PS as it mostly affects hotspot testing, the patch will be pushed to jdk/hs.
>> webrev: http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
>> testing: java/util/Arrays/TimSortStackSize2.java  w/ and w/o externally 
>> provided Xmx value
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8190679
>> Thanks,
>> -- Igor

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

[Xueming Shen]

+1

On 2/27/18, 11:37 AM, Joe Wang wrote:

Hi Sherman and all,

Thanks for the further reviews!

Here's the latest webrev with boundary checks in 
StringLatin1/StringUTF16:


JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/

Best,
Joe

On 2/22/2018 6:07 PM, Joe Wang wrote:



On 2/22/18, 12:51 PM, Xueming Shen wrote:

On 2/22/18, 12:04 PM, Joe Wang wrote:

Hi Sherman,

Thanks for reviewing the change.

Taking a local copy of the count field, but the boundary check 
would be almost immediately done against the field itself. Are you 
worrying about the count field may be out of sync with the byte 
array? I would think that's unlikely to happen. Whether it's 
StringBuilder or StringBuffer, it's not advisable/practical to use 
in multiple threads. In a valid usage, the count is always 
consistent with the byte array.




Hi Joe,

It might not be a "valid usage" but it did happen and when it 
happens it might just crash the
vm without those boundary checks. It's especially true for those 
intrinsics methods with explicit
comments "intrinsic performs no bounds checks". In this case, the 
StringUTF16.getChar() is being
called in new public method StringUTF16.compareTo(byte[], byte[], 
int, int) without appropriate
boundary check. In the "old" code the "index" is guaranteed to be 
within [0, len) in
StringUTF16.compareTo(byte[], byte[]), so it's safe. A real case for 
such scenario can be found in

JDK-8158168 [1], for example.


Thanks for the pointer! The email thread helps a lot. I've updated 
the webrev with a boundary check in ASB (AbstractStringBuilder line 
106, 107), and then a note to StringUTF16.compareTo (StringUTF16 line 
280). Hopefully this is sufficient. Didn't want to add any check in 
StringUTF16 since that may affect the original two-arg method.


JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/

-Joe



-Sherman


[1] https://bugs.openjdk.java.net/browse/JDK-8158168

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

[Joe Wang]

Hi Sherman and all,

Thanks for the further reviews!

Here's the latest webrev with boundary checks in StringLatin1/StringUTF16:

JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/

Best,
Joe

On 2/22/2018 6:07 PM, Joe Wang wrote:



On 2/22/18, 12:51 PM, Xueming Shen wrote:

On 2/22/18, 12:04 PM, Joe Wang wrote:

Hi Sherman,

Thanks for reviewing the change.

Taking a local copy of the count field, but the boundary check would 
be almost immediately done against the field itself. Are you 
worrying about the count field may be out of sync with the byte 
array? I would think that's unlikely to happen. Whether it's 
StringBuilder or StringBuffer, it's not advisable/practical to use 
in multiple threads. In a valid usage, the count is always 
consistent with the byte array.




Hi Joe,

It might not be a "valid usage" but it did happen and when it happens 
it might just crash the
vm without those boundary checks. It's especially true for those 
intrinsics methods with explicit
comments "intrinsic performs no bounds checks". In this case, the 
StringUTF16.getChar() is being
called in new public method StringUTF16.compareTo(byte[], byte[], 
int, int) without appropriate
boundary check. In the "old" code the "index" is guaranteed to be 
within [0, len) in
StringUTF16.compareTo(byte[], byte[]), so it's safe. A real case for 
such scenario can be found in

JDK-8158168 [1], for example.


Thanks for the pointer! The email thread helps a lot. I've updated the 
webrev with a boundary check in ASB (AbstractStringBuilder line 106, 
107), and then a note to StringUTF16.compareTo (StringUTF16 line 280). 
Hopefully this is sufficient. Didn't want to add any check in 
StringUTF16 since that may affect the original two-arg method.


JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/

-Joe



-Sherman


[1] https://bugs.openjdk.java.net/browse/JDK-8158168

Re: [JDK 11] RFR 8196759: Move two java/text/Normalizer tests into OpenJDK

[Naoto Sato]

Looks good.

Naoto

On 2/26/18 10:51 PM, Chris Yin wrote:

Please review the changes to move two java/text/Normalizer tests to OpenJDK 
jdk_text group, thanks

bug: https://bugs.openjdk.java.net/browse/JDK-8196759 

webrev: http://cr.openjdk.java.net/~xiaofeya/8196759/webrev.00/ 


Regards,
Chris

Re: RFR: 8198755: Reduce cost of InvokerBytecodeGenerator::isStaticallyInvocable/-Nameable

[Claes Redestad]

On 2018-02-27 17:53, John Rose wrote:

Looks good.


Thanks!

I'll revert for-loop (it was a remnant of an earlier experiment to see
if getting rid of the ptypes.clone() mattered for startup: it didn't, 
really)


/Claes

Re: RFR: 8198755: Reduce cost of InvokerBytecodeGenerator::isStaticallyInvocable/-Nameable

[John Rose]

Looks good.

On Feb 27, 2018, at 8:42 AM, Paul Sandoz  wrote:
> 
> 
> 
>> On Feb 27, 2018, at 7:42 AM, Claes Redestad  
>> wrote:
>> 
>> Hi,
>> 
>> when generating LF classes with InvokerBytecodeGenerator, almost 5% of 
>> executed code is concerned with determining if members and parameters are 
>> statically invocable and/or nameable, which we can assert is always true for 
>> MethodHandle arguments.
>> 
> 
> IIRC this is for the case where we can reliably crack open the method handle 
> (from it’s member name) and invoke it directly?

Yes, invoked directly from inside LF code in java.lang.invoke.

The 'member' parameter already gives evidence that somebody
has gotten the right to call the method indirectly via a MH,
and the LF generator wants to lower that to a direct invocation
at bytecode level.

That's why MH package-private members are called directly.

> 
>> Since MethodHandle targets and parameters are common, it's a profitable 
>> startup optimization to add a fast-path test for this.
>> 
>> Webrev: http://cr.openjdk.java.net/~redestad/8198755/jdk.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198755
>> 
> 
> 
> 957 for (int i = 0; i < mtype.parameterCount(); i++)
> 958 if (!isStaticallyNameable(mtype.parameterType(i)))
> 
> Revert back to: 
> 
> for (Class ptype : mtype.parameterArray())
>  if (!isStaticallyNameable(ptype))
> 
> ?

+1

— John

Re: RFR: 8198755: Reduce cost of InvokerBytecodeGenerator::isStaticallyInvocable/-Nameable

[Paul Sandoz]

> On Feb 27, 2018, at 7:42 AM, Claes Redestad  wrote:
> 
> Hi,
> 
> when generating LF classes with InvokerBytecodeGenerator, almost 5% of 
> executed code is concerned with determining if members and parameters are 
> statically invocable and/or nameable, which we can assert is always true for 
> MethodHandle arguments.
> 

IIRC this is for the case where we can reliably crack open the method handle 
(from it’s member name) and invoke it directly?


> Since MethodHandle targets and parameters are common, it's a profitable 
> startup optimization to add a fast-path test for this.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8198755/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198755
> 


 957 for (int i = 0; i < mtype.parameterCount(); i++)
 958 if (!isStaticallyNameable(mtype.parameterType(i)))

Revert back to: 

 for (Class ptype : mtype.parameterArray())
  if (!isStaticallyNameable(ptype))

?

Paul.

RFR: 8198755: Reduce cost of InvokerBytecodeGenerator::isStaticallyInvocable/-Nameable

[Claes Redestad]

Hi,

when generating LF classes with InvokerBytecodeGenerator, almost 5% of 
executed code is concerned with determining if members and parameters 
are statically invocable and/or nameable, which we can assert is always 
true for MethodHandle arguments.


Since MethodHandle targets and parameters are common, it's a profitable 
startup optimization to add a fast-path test for this.


Webrev: http://cr.openjdk.java.net/~redestad/8198755/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8198755

Thanks!

/Claes

Re: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java

[Alan Bateman]

On 27/02/2018 15:04, Adam Farley8 wrote:

Resending. Bump. :)

On 14/02/2018 14:13, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code 
included

>> in the bug) and:
>>
>> 1) Complete the CSR process for the new JNI Return code.
>> 2) Commit the changes that contain (a) the new return code, and (b) the
>> non-Hotspot code that handles the new code.
> The patches attached to the JIRA issue are missing the changes to the
> JVM TI spec (jvmti.xml).

I'm not seeing the JNI return codes in that file. Are you after one of 
those

dated updates near the bottom?
e.g.
```

RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java

[Adam Farley8]

Resending. Bump. :)

On 14/02/2018 14:13, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code 
included
>> in the bug) and:
>>
>> 1) Complete the CSR process for the new JNI Return code.
>> 2) Commit the changes that contain (a) the new return code, and (b) the
>> non-Hotspot code that handles the new code.
> The patches attached to the JIRA issue are missing the changes to the 
> JVM TI spec (jvmti.xml). 

I'm not seeing the JNI return codes in that file. Are you after one of 
those
dated updates near the bottom?
e.g.
```
  
  Added JNI_SILENT_EXIT return code for early exits without errors.
  java.c's ParseArguments function now sets pret value to 2 for a NULL 
pwhat.
 This allows us to clearly identify when no class was set, but no 
other error has occurred.
 This is undone in java.c's ContinueInNewThread method, so the 
surface behaviour does not change. 
  
```

> There is also text to be written for the JNI spec if this proposal goes 
> ahead.

I assume you mean the "RETURNS" section of the JNI_CreateJavaVM 
bit on the invocation.html web page. Something like this?

```
RETURNS:
Returns JNI_OK on success; returns a suitable JNI error code (a negative 
number) on failure.

The sole exception is a silent exit, which returns JNI error code 
JNI_SILENT_EXIT. 
This indicates that the VM cannot be used, but that this is the intended 
behaviour for the 
arguments used. E.g. -Xlog:help (which prints help output and then 
destroys the VM)
```

>
> I don't agree that the launcher should be looking for 
> "-agentlib:jdwp=help" in the command line as it's just one of many ways 
> that the debugger agent might be started (e.g. -Xrunjdwp:, 
> _JAVA_TOOLS_OPTIONS, ...).

We can avoid that by finding a way around this line in ContinueInNewThread 
(java.c):

```
return (ret != 0) ? ret : rslt;
```

I have devised a means to do this, as outlined in the jvmti.xml change 
above. I put the
changes into a recent clone of jdk/jdk, and attached the hg diff, along 
with an improved
test.



If you have Author or Committer privileges, could you add the files to the 
bug please?

>
>> Backporting would be appreciated, but is optional.
> I don't think these changes are appropriate to backport as they include 
> specification changes/
>
>-Alan

This is fair.

- Adam

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

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

[Adam Farley8]

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 
To: Peter Levart , Adam Farley8 

Cc: "hotspot-...@openjdk.java.net developers" 
, core-libs-dev 

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