| Hi Brian,
A few questions.
The stack trace below does not appear to be the full stack trace
Does this occur when running against any other App Server such as Glassfish?
Is it possible the issue is being influenced by the porting package for Open Liberty?
How is the TCK being run: the command line via tsant or the GUI?
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?
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?
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
What other differences to you have in your ts.jte configuration between JDK 8 and 11?
Best Lance
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
Hi Kevin,
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:
Thanks, Alwin.
The options you referenced are for the "heap size", not the "stack size". The scripts you referenced do not seem to be setting the "stack size" (-Xss), so maybe that's being set outside of these scripts as just part of the environment configuration?
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Alwin Joseph <alwin.joseph@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Kevin Sutter <sutter@xxxxxxxxxx>
Date: 05/20/2020 13:51
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Hi Kevin,
For running platform TCK against glassfish we change the default memory settings in VI, RI and the TCK only for ejb30 tests. This configuration change is done from [1] to [2]. The maximum memory is increased in the bin/ts.jte for the TCK to Xmx4096m for the platform TCK run in CI [2].
[1] https://github.com/eclipse-ee4j/jakartaee-tck/blob/38cb27458e1ace61de3eb767713136c9484d130e/docker/run_jakartaeetck.sh#L251
[2] https://github.com/eclipse-ee4j/jakartaee-tck/blob/38cb27458e1ace61de3eb767713136c9484d130e/docker/run_jakartaeetck.sh#L259
HTH,
Alwin Joseph
On 20/05/20 11:58 PM, Kevin Sutter wrote:
Hi,
Does anybody know the stack size that is used when running the Platform TCK for Jakarta EE 9? Some of you know that we (IBM) have been hitting a couple of issue when attempting to run the TCK with HotSpot (works with OpenJ9). We've recently discovered that we can get around the problem by doubling the default stack size to 2048k (-Xss2048k). Since everyone's environment might be setup slightly different, I'm wondering what our Jakarta EE runs use for the stack size? And, whether this is a configurable item that needs to be updated somewhere in the TCK configuration? Or, maybe it's already set at a higher value and our (IBM) environment was out of sync. Thanks!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037Oracle Java Engineering 1 Network Drive Burlington, MA 01803Lance.Andersen@xxxxxxxxxx
|
