PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test)

Jini George jini.george at oracle.com
Tue Jul 19 05:12:48 UTC 2016


Thank you, Serguei, for the review. 

 

You are right, getBytesPerWord() makes more sense. Hence I modified the code to use getBytesPerWord(), though both those (getAddressSize() and getBytesPerWord()) seem to return the same value. I have retained the call to alignSize() since the header size is not multiplied by word size.

 

I have addressed the comments related to the test cases. Here is a modified webrev:

 

http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.01/

 

Would you please take a relook ?

 

Thank you,

Jini.

 

 

From: Serguei Spitsyn 
Sent: Friday, July 15, 2016 3:21 PM
To: Jini George; serviceability-dev at openjdk.java.net
Subject: Re: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test)

 

Hi Jini,

Some questions.

Is the call of the method alignSize(size) necessary?
It seems that the size is already aligned by the way it is calculated as the number of words is multiplied to wordLength.
But I'm not exactly sure because the wordLength is returned by VM.getVM().getAddressSize()
but the VM.getVM().getBytesPerWord() is used in the alignSize:

public static long alignSize(long size) {
  // natural word size
  return VM.getVM().alignUp(size, VM.getVM().getBytesPerWord());
}

So, the question is why did you use the getAddressSize() but not the getBytesPerWord()?
Do they always return the same number?
Just would like to understand your reasoning. :)

Some nits:

test/serviceability/sa/TestInstanceKlassSize.java

 138                 for (String s:output.asLines()) {
 139                     if (s.contains (instanceKlassName)) {
 140                        Asserts.assertTrue(
 141                           s.contains (jcmdInstanceKlassSize),
 ...
 166         for (String SAInstanceKlassName:SAInstanceKlassNames) {
 

A space is needed after the ':' sign at L138, L166. Space is not needed after the 'contains' at L139, L141. test/serviceability/sa/TestInstanceKlassSizeForInterface.java 

 138             for (String s:SAOutput.asLines()) {
 139                 if (s.contains (instanceKlassName)) {
 140                    Asserts.assertTrue(
 141                       s.contains (jcmdInstanceKlassSize),

A space is needed after the ':' sign at L138. Space is not needed after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 19:07, Jini George wrote: 

Hi,

 

Gentle Reminder!

 

Thanks,

Jini.

 

From: Jini George Sent: Tuesday, July 05, 2016 9:54 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test)

 

Hi all, 

 

Please review the fix in Serviceability Agent (SA) for:

HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145627"JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test)

 

The webrev is at: 

HYPERLINK "http://cr.openjdk.java.net/%7Esballal/sponsorship/8145627/webrev.00/"http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ 

 

The modifications include the fix and 2 tests to check the InstanceKlass sizes representing some well known classes and that of an interface.  The tests compare the sizes returned by SA to those returned by jcmd. At this point, SA cannot view the InstanceKlasses representing anonymous classes. (This issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160228"JDK-8160228 (SA cannot view the LambdaMetaFactory generated anonymous instanceKlasses)). Hence the current fix does not include the size addition for InstanceKlasses representing anonymous classes.

 

Thanks,

- Jini Susan George

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160718/27e06236/attachment.html>


More information about the serviceability-dev mailing list