JDK-8342638 : java/awt/Robot/InfiniteLoopException.java fails with OOME after JEP486
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 24,25
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux,windows
  • CPU: generic
  • Submitted: 2024-10-18
  • Updated: 2025-05-03
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8338411 - Implement JEP 486: Permanently Disable the Security Manager
Sub Tasks
JDK-8344881 :  
Problemlist java/awt/Robot/InfiniteLoopException.java on Linux - Resolved
Description
This test was seen to fail initially on jep486 branch, Now fails in mainline too.

There seems to be some kind of side effect of SM removal on this test although the test wasn't modified as part of SM removal.

It happens on windows platform only. Locally the issue is reproducible when heap space is reduced to 128m and seems to pass when heap space is increased. But fixing the test by just increasing heap size will mask the real issue which may be a regression caused by SM changes.

To replicate it locally on windows run with the following jtreg tag:
 @run main/othervm -Xmx128m InfiniteLoopException
Comments
> Should it be problemlisted for linux too? Yes, I have created a JBS to PList it on linux - JDK-8344881
22-11-2024
> The test is problemlisted on windows, now it is seen to fail similarly on linux nodes in CI. Should it be problemlisted for linux too?
22-11-2024
[~honkar] Since test is failing on linux machine too, I think JBS summary and OS label should be changed.
22-11-2024
[~honkar] Here comes the question what is the heap size of the test where it fails. To find it out, some option may need to be added… GC logging? jtreg is run with ‘-Xmx768m -XX:MaxRAMPercentage=25’. [~dholmes] A great way to estimate the difference in performance. We may also add another counter to see how many repaints are handled. As far as I can see, `Thread.yield` does nothing…
21-11-2024
It would be interesting to add a counter to this loop 51: while (frame.isDisplayable()) { 52: frame.repaint(); 53: Thread.yield(); 54: } and report it at the end, to see how many times we loop before and after the SM removal. It may simply be a matter of less code to run resulting in better JIT'ing and so much faster performance that outpaces the GC.
21-11-2024
[~aivanov] > I wonder if OOME occurs on Mac or Linux if the test is run with small heap. Locally I'm able to replicate the OOME issue on Mac and Linux for very small heap size -Xmx5m vs Windows which fails with OOME at -Xmx128m. I think -Xmx5m is very small, may be there is lower limit on required heap size for running such tests ? I tried to get to the root cause and still not sure what causes this issue to surface more prominently once SecurityManager is removed.
20-11-2024
The test is problemlisted on windows, now it is seen to fail similarly on linux nodes in CI.
18-11-2024
The test should be run in `othervm` mode, and it is, the log contains: Mode: othervm Yes, it seems that infinite loop threads are run faster now…
18-11-2024
If the test is running in AgentVM mode it may be changes to other tests (affected by the SM removal) that now cause this test to fail. It could even be reduced interference causing the infinite loop threads to run much more frequently and so outpace the GC.
17-11-2024
Now failing in mainline too.
17-11-2024
It throws OOME exception for two different cases. 1) robot.waitForIdle() is slow: Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-2" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-1" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-3" java.lang.RuntimeException: Too slow:47 at InfiniteLoopException.test(InfiniteLoopException.java:65) at InfiniteLoopException.main(InfiniteLoopException.java:42) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:572) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1491) JavaTest Message: Test threw exception: java.lang.RuntimeException: Too slow:47 -------------------- 2) OOME: Java heap space error Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-2" java.lang.OutOfMemoryError: Java heap space at java.desktop/java.awt.Component.repaint(Component.java:3493) at java.desktop/java.awt.Component.repaint(Component.java:3395) at InfiniteLoopException.lambda$test$0(InfiniteLoopException.java:52) at InfiniteLoopException$$Lambda/0x0000013db9001208.run(Unknown Source) at java.base/java.lang.Thread.runWith(Thread.java:1504) at java.base/java.lang.Thread.run(Thread.java:1491) java.lang.OutOfMemoryError: Java heap space at java.desktop/java.awt.Component.repaint(Component.java:3493) at java.desktop/java.awt.Component.repaint(Component.java:3395) at InfiniteLoopException.lambda$test$0(InfiniteLoopException.java:52) at InfiniteLoopException$$Lambda/0x0000013db9001208.run(Unknown Source) at java.base/java.lang.Thread.runWith(Thread.java:1504) at java.base/java.lang.Thread.run(Thread.java:1491) STATUS:Failed.STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: Java heap space `main' threw exception: java.lang.OutOfMemoryError: Java heap space
12-11-2024