JDK-8236917 : TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match"
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-10
  • Updated: 2024-06-27
  • Resolved: 2020-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15
11.0.25Fixed 15 b06Fixed
Related Reports
Duplicate :  
JDK-8236982 - Tests serviceability/sa/TestInstanceKlassSize*.java fail after JDK-8232759
Relates :  
JDK-8237111 - LingeredApp should be started with getTestJavaOpts
Relates :  
JDK-8232759 - Remove GC.class_stats
Description
java.lang.RuntimeException: The size computed by SA forjava.lang.Object does not match.: expected true, was false
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
	at TestInstanceKlassSize.startMeWithArgs(TestInstanceKlassSize.java:114)
	at TestInstanceKlassSize.main(TestInstanceKlassSize.java:156)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:832)

JavaTest Message: Test threw exception: java.lang.RuntimeException: The size computed by SA forjava.lang.Object does not match.: expected true, was false
JavaTest Message: shutting down test

Same failure with TestInstanceKlassSizeForInterface.java.
Comments
Fix Request (jdk11u) I would like to backport this patch to JDK11u. Clean backport.
26-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2712 Date: 2024-05-16 19:43:53 +0000
16-05-2024
URL: https://hg.openjdk.java.net/jdk/jdk/rev/b218684fc61b User: coleenp Date: 2020-01-15 13:11:19 +0000
15-01-2020
Summary from slack discussion. The initial test process, as executed by jtreg through the @run directive, is used to launch a LingeredApp, then launch a second version of the test to invoke the SA on the LingeredApp, and then do the same WhiteBox calculation for comparison. The second test process, using createJavaProcessBuilder, is not relevant to the problem and hence why passing true/false to createJavaProcessBuilder made no difference. So the initial test @run process will get: - java opts from jtreg - vm opts from jtreg - explicit args from @run But the LingeredApp process is only getting vm opts via the Utils.getVmOptions() function. Hence if a significant flag came in via java opts the test would fail - as it did for my local experiment. And as it turns out our CI testing passes configuration arguments via "java opts" not "vm opts", hence that too would trigger a failure when e.g. -Xshare:off is passed in. Part of the problem here is that we now use two very different processes to get the SA numbers and the WB numbers and so those two processes must be identical with respect to anything that affects the sizes being calculated. The original test queried the SA of the LingeredApp and ran jcmd against the LingeredApp - hence the numbers came from the same process. It would be better if only one process was used for both calculations, but there's no API to execute WB operations on a remote process. Simple solution, as Coleen proposes, is to change the test to apply Utils.getTestJavaOpts() which combined "java opts" and "vm opts" when exec'ing the LingeredApp.
13-01-2020
If I run the test locally with no options it passes. If I run with -vmoption:-Xshare:off it passes. If I run with -javaoption:-Xshare:off it fails. That suggests to me that the VM exec'd by the test does not get javaoptions passed through to it. But if I change the test to do: ProcessBuilder processBuilder = ProcessTools .createJavaProcessBuilder(true, toolArgs); the behaviour is unchanged. This isn't making any sense.
13-01-2020
[~dholmes] No, that's not the issue. I tried that. See above. test.vm.opts is not set by the mach5 version of jtreg (?) I think it's jtreg that does this. my jib based jtreg is javatestVersion=6.0-ea+b03-2018-08-16 jtregVersion=jtreg 4.2 fcs b16 in mach5 it says the same thing: javatestVersion=6.0-ea+b03-2018-08-16 jtregVersion=jtreg 4.2 fcs b16
13-01-2020
It should be using test.vm.opts to pass flags submitted to the JVM under test. test.java.opts is used to pass flags to all VMs ie javac, jcmd etc as well as java.
12-01-2020
Isn't the issue with this code: // Start a new process to attach to the LingeredApp process ProcessBuilder processBuilder = ProcessTools .createJavaProcessBuilder(toolArgs); which calls: public static ProcessBuilder createJavaProcessBuilder(String... command) { return createJavaProcessBuilder(false, command); } Note the "false". This in turn calls: public static ProcessBuilder createJavaProcessBuilder(boolean addTestVmAndJavaOptions, String... command) { so that we don't add either set of flags: * @param addTestVmAndJavaOptions If true, adds test.vm.opts and test.java.opts * to the java arguments.
12-01-2020
So changing the test to call getTestJavaOpts makes it pass but I really want to know why test.vm.opts was changed to not pass the VM options.
12-01-2020
In the version of jtreg that I'm using from "make test TEST=serviceability/sa/TestInstanceKlass.java", this is -Dtest.java.opts -Dtest.vm.opts='-XX:MaxRAMPercentage=3 -Xshare:off' \\ -Dtest.tool.vm.opts='-J-XX:MaxRAMPercentage=3 -J-Xshare:off' \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ Is this an intentional change to jtreg and which is correct? I have an up-to-date repo and build using jib. I assume that we wanted the vm options. If you grep for getVmOptions there are a lot of tests that use this. Maybe all of these should be changed and remove getVmOptions if this is no longer going to pass the VM options.
11-01-2020
Looks like the following isn't working: vmArgs.add("-XX:+UsePerfData"); vmArgs.addAll(Utils.getVmOptions()); app = LingeredApp.startApp(vmArgs); Since -XX:+UsePerfData is being passed, I guess Utils.getVmOptions() does not return what we expect it to. In the log I also see: -Dtest.vm.opts=-XX:MaxRAMPercentage=6 \\ -Dtest.java.opts='-Xshare:off -showversion' \\ We seem to be getting the test.vm.opts. I think we want test.java.opts, which would mean calling addTestJavaOpts(), or we want both vm and java opts, which would mean calling getTestJavaOpts()
11-01-2020
Yes, it fails in mach5 but not locally. But it looks like the class-stats change broke it (except I fixed this test to work locally).
10-01-2020
Are you sure it is actually running locally, and is not being skipped due to attach not being supported?
10-01-2020
I suspect this is due to JDK-8232759. Coleen, could you please have a look?
10-01-2020