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 7:50 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote:

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

com.sun.ts.lib.harness.TSScript.invokeCommand() launches a Java process. From attaching a debugger to that launched process, I can see that it immediately runs into the StackOverflowError before doing anything else. If you glue the top and bottom of the stack that I provided together, you'll see that it entirely consists of JDK internals. It's not executing any harness or CTS code at all before it blows up. I don't know what the JDK code in question is trying to do or why it loops through itself a bunch of times with either flavor of Java 11.

I would still try removing testsuite.jtd and see if you see the same behavior when the binary finder is not there.  One of the first things needed to be done by jtharness  is find the available tests,  When running CTS or any standalone TCK out of a workspace, the binary finder is not used


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

Whichever one is included in the 8.0.2 TCK, and that appears to be version 5.

re: other TCKs
The only other TCKs we typically run separately are BeanValidation and CDI both of which use an entirely different testing mechanism (Arquillian, etc.), so I'm skeptical as to whether they'd be useful for this discussion, but they are on my to-do list.

Given BV and CDI TCKs do not use jtharness, yes that is not applicable.

I am referring to TCKs such as JPA,  Servlet, JSF, etc which use jtharness.  Assuming it is the same version of javatest,  This could be helpful in narrowing down the issue

Best
Lance


-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:22:02 PM---> On May 21, 2020, at 1:04 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote: >

From:  Lance Andersen <lance.andersen@xxxxxxxxxx>
To:  jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date:  05/21/2020 06:22 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





      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

<1C222967.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