| Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9? |
A "few" questions? Methinks you understate. :)
"The stack trace below does not appear to be the full stack trace"
This is true, I only showed the very bottom of the stack to show that this is indeed occurring right from trying to load the main class before it gets anywhere into actual test/framework code. From etc. up it just repeats what I already showed a bajillion times, resulting in something like this at the top:
Exception in thread "main" java.lang.StackOverflowError
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at java.base/java.net.URL.lookupViaProperty(URL.java:1257)
at java.base/java.net.URL.getURLStreamHandler(URL.java:1416)
at java.base/java.net.URL.<init>(URL.java:451)
at java.base/jdk.internal.loader.URLClassPath$JarLoader.<init>(URLClassPath.java:719)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444)
at java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:695)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at java.base/java.net.URL.lookupViaProperty(URL.java:1261)
at java.base/java.net.URL.getURLStreamHandler(URL.java:1416)
at java.base/java.net.URL.<init>(URL.java:451)
...
"Does this occur when running against any other App Server such as Glassfish?"
No idea. Our intention was to inform the community so they could go see if they have the same problem when trying to run with their app servers. Glassfish doesn't support Java 11 yet, does it?
"Is it possible the issue is being influenced by the porting package for Open Liberty?"
Anything's possible I suppose, but considering it's not even loading the main class after this Java process is spawned, I don't see how. People trying this with their own app server/porting package would be a useful data point for this. It's easily reproducible for us just by trying to run the EE8 TCK with Java 11.
"How is the TCK being run: the command line via tsant or the GUI?"
Command line. This was first detected in our automated runs, which all use the command line.
"If you are running java test from the command line, do you see the same issue if you just start up the GUI without running a test?"
No idea. I'm relatively new in this role and have never tried to do anything with the GUI.
"Do you notice the same issue running one of the standalone TCKs or just the platform TCK? Same issue when running in Web Profile mode?"
I haven't tried any other TCKs or modes with Java 11 yet. It's early days.
"Have you tried to narrow down the issue with a simplified test case as it would be useful to see understand the difference between J9 and Hotspot. This would be useful if possible"
No, I haven't. I've been working with some Java contacts internal to us, but we haven't gotten that far yet. For what it's worth, I have attached a debugger to both and I can see the stack growing with the same URL.<init>-related stack in both. It just apparently doesn't get nearly as big in J9 before doing whatever it's trying to do.
"What other differences to you have in your ts.jte configuration between JDK 8 and 11?"
Very little. All that's needed to get things to run is removing the -Djava.endorsed.dirs argument, as it's no longer supported.
-Brian
Brian Decker
Rochester Blizzard
Jakarta Platform TCK Lead
Home Office
(612) 216-4881
Roch. Office
t/l 553-4686
bmdecker@xxxxxxxxxx
Lance Andersen ---05/21/2020 06:50:41 AM---Hi Brian, A few questions.
From: Lance Andersen <lance.andersen@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 05/21/2020 06:50 AM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
I've been the one tinkering with this for us [IBM], and here's what I've found so far.
The problem is specific to running with Java 11. I've found that using -Xss1088k with the Hotspot JDK is sufficient to avoid the error. This is just a touch above the default value of 1024k; however, it is a massive step up from what is needed with Java 8. I am able to run the TCK just fine while specifying the minimum allowed value of -Xss228k with Hotspot Java 8.
I also took some diagnostics using the OpenJ9 version of both Java 8 and Java 11 and see a similar uptick there, although both needed stacks far smaller than the corresponding Hotspot release, which is how it has served as a workaround without needing to change java options.
OpenJ9 JDK 8: ~5k
OpenJ9 JDK 11: ~187k
It is sufficient to add the -Xss argument into command.testExecute in ts.jte. That's what I've been doing locally to test all of this out. The problem occurs when running any test in the entire TCK as it occurs when first trying to initialize and load classes:
... etc.
[23] java.lang.ClassLoader.loadClass (ClassLoader.java:521)
[24] java.net.URL.lookupViaProperty (URL.java:1,261)
[25] java.net.URL.getURLStreamHandler (URL.java:1,416)
[26] java.net.URL.<init> (URL.java:451)
[27] jdk.internal.loader.URLClassPath$JarLoader.<init> (URLClassPath.java:719)
[28] jdk.internal.loader.URLClassPath$3.run (URLClassPath.java:493)
[29] jdk.internal.loader.URLClassPath$3.run (URLClassPath.java:476)
[30] java.security.AccessController.doPrivileged (native method)
[31] jdk.internal.loader.URLClassPath.getLoader (URLClassPath.java:475)
[32] jdk.internal.loader.URLClassPath.getLoader (URLClassPath.java:444)
[33] jdk.internal.loader.URLClassPath.getResource (URLClassPath.java:313)
[34] jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull (BuiltinClassLoader.java:695)
[35] jdk.internal.loader.BuiltinClassLoader.loadClassOrNull (BuiltinClassLoader.java:621)
[36] jdk.internal.loader.BuiltinClassLoader.loadClass (BuiltinClassLoader.java:579)
[37] jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass (ClassLoaders.java:178)
[38] java.lang.ClassLoader.loadClass (ClassLoader.java:521)
[39] java.lang.Class.forName0 (native method)
[40] java.lang.Class.forName (Class.java:398)
[41] sun.launcher.LauncherHelper.loadMainClass (LauncherHelper.java:760)
[42] sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:655)
Brian Decker
Rochester Blizzard
Jakarta Platform TCK Lead
Home Office
(612) 216-4881
Roch. Office
t/l 553-4686
bmdecker@xxxxxxxxxx
<graycol.gif>Alwin Joseph ---05/20/2020 03:58:36 PM---Hi Kevin, Oops sorry. Yes, I was referring to the heap memory setting we used for
From: Alwin Joseph <alwin.joseph@xxxxxxxxxx>
To: Kevin Sutter <sutter@xxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 05/20/2020 03:58 PM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
Oops sorry. Yes, I was referring to the heap memory setting we used for Jakarta EE 8 TCK runs. ( we are yet to run Platform TCK for Jakarta EE 9).
I cannot find any configurable setting to alter the stack size (-Xss) within the TCK. We could check if the test run commands in ts.jte (command.testExecute*) can be made use of, to add the stack size.
Can you share details of the default stack size that was changed for IBM run if the change was within the TCK source. It would also help to know for future reference, which specific tests needed the change in stack size to run.
Regards,
Alwin Joseph
On 21/05/20 1:26 AM, Kevin Sutter wrote:
