RFR: 8360707: Globally enumerate all blobs, stubs and entries
Andrew Dinn
adinn at openjdk.org
Mon Jun 30 16:17:42 UTC 2025
On Mon, 30 Jun 2025 06:14:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:
>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> @adinn I got one test failure on s390: `test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java`
>
>
> java.lang.RuntimeException: 1 < 2
> at jdk.test.lib.Asserts.fail(Asserts.java:715)
> at MachCodeFramesInErrorFile.run(MachCodeFramesInErrorFile.java:170)
> at MachCodeFramesInErrorFile.main(MachCodeFramesInErrorFile.java:108)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> at java.base/java.lang.Thread.run(Thread.java:1474)
>
>
> I didn't hs_err even in full verbose. But attaching overall run in txt file:
> [26004_test_failure.txt](https://github.com/user-attachments/files/20973513/26004_test_failure.txt)
@offamitkumar I managed to run the test on an s390x build and it passed. I didn't get any hserr output in the jtr file when I set DEBUG on the command line. So, I modified the test to write the hserr file to system.err unconditionially (i.e. I changed the if at line 137 of MachCodeFramesInErrorFile.java to 'if (true)'.
The System.err output in the jtr file contained [MachCode] sections for 4 compiled methods, including the two that appeared in the stack listing (crashInJava3 and crashInJava2). So, I'm not sure why it is failing.
n.b. not all the System.err output ends up in the jtr file because the test harness truncates excessive output. However, I wonder if the problem you are seeing is because the original hserr file is being truncated. It includes a message to that effect starting "Output overflow: ..."
If that is the case and if you can reproduce the problem after modifying the test to write the hserr contents unconditionally then you ought to be able to see all the file contents by setting system property javatest.maxOutputSize to a suitable value (default is 100000).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3019815902
More information about the shenandoah-dev
mailing list