Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?


On May 21, 2020, at 1:04 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote:

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)
...


Well from the above you cannot tell if the failure occurs within the harness or somewhere with CTS

Be interesting to know if it you get any further by removing testsuite.jtd

"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?

Not sure if JDK 11 support  is there for Glassfish. 


"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.

It would be worth trying to start the GUI and see where you get.

What version of javatest is being used? 4.6 or 5?


"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.

This would be a good thing to try as a datapoint or try 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"
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

<graycol.gif>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




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
      On May 20, 2020, at 5:32 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote:

      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:

      _______________________________________________
      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

<1C706724.gif>

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx


_______________________________________________
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


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx



Back to the top