RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines

[Daniil Titov]

Hi Leonid,

I run the test with -XComp at Mach5 linux-x64-debug builds before and after the changes the forwards VM and test options to j-* tools 
 and here is the difference in the execution times for some serviceability/sa tests:

serviceability/sa/sadebugd/SADebugDTest.java, before : 2m 23s ,  after:11m 07s
serviceability/sa/sadebugd/TestJmapCore.java,  before : 42s ,  after:1m 09s
serviceability/sa/TestSysProps.java, before : 36s ,  after:1m 27s

Thus for the most of the tests the  overhead is about 2 times although in case of serviceability/sa/sadebugd/SADebugDTest.java it spikes up to 5 times.

Best regards,
Daniil
 
On 4/23/20, 11:23 AM, "Leonid Mesnik" <leonid.mesnik at oracle.com> wrote:

    Hi Daniil

    Have you checked how longer tests are executed with adding java options 
    to launchers (with Xcomp/Graal/ZGC)?

    If the overhead is not significant might be it make worth to add options 
    by default? The idea is to add vm.opts to all processes and java.opts to 
    tested only. But if you believe that adding java.opts to jdk tools helps 
    to improve testing then it is better just to add it by default.  It 
    helps to avoid similar failures in the future or with highly concurrent 
    execution (when tens of jaotc are started for example).

    Leonid

    On 4/23/20 11:10 AM, Chris Plummer wrote:
    > On 4/23/20 10:18 AM, Daniil Titov wrote:
    >> Hi Chris,
    >>
    >> I will revoke this RFR and resubmit it under JDK-8242009
    >> with the changes you suggested to use Utils.getTestJavaOpts()
    >> and make JDKToolLauncher to have an option to forward VM options.
    >>
    > It could also be done with a new API such as 
    > JDKToolLauncher.addVMArgs(). That might be better than a new "create" 
    > API.
    >
    > thank,s
    >
    > Chris
    >>> Is your change causing -Xshowversion to be passed?
    >> Yes, the changes makes  tests  run with -Xshowversion to be passed.
    >>
    >>> Do you know where it  is coming from?
    >> It is coming from task definitions for different tiers.
    >>
    >> Thank you,
    >> Daniil
    >>
    >> On 4/22/20, 12:54 PM, "Chris Plummer" <chris.plummer at oracle.com> wrote:
    >>
    >>      Hi Daniil,
    >>
    >>      Thanks for cleaning this up. I think this should be fixed under
    >>      JDK-8242009. JDK-8238561 involves more than just this one issue.
    >>
    >>      Is there a reason why you didn't just change JDKToolLauncher to 
    >> have an
    >>      option or API to add the args?
    >>
    >>      Why are you calling Utils.addTestJavaOpts() instead of
    >>      Utils.getTestJavaOpts()?
    >>
    >>      Is your change causing -Xshowversion to be passed? Do you know 
    >> where it
    >>      is coming from?
    >>
    >>      thanks,
    >>
    >>      Chris
    >>
    >>      [1] https://bugs.openjdk.java.net/browse/JDK-8242009
    >>
    >>      On 4/22/20 10:48 AM, Daniil Titov wrote:
    >>      > Please review the change [1] that ensures that VM and test 
    >> options are forwarded to
    >>      >   j*-tools when they are launched from serviceability/sa tests.
    >>      >
    >>      > In particular, it will ensure that passed to the tests maximum 
    >> heap size settings ( -XX:MaxRAMPercentage)
    >>      > are also honored by  j*-tools serviceability/sa  tests launch.
    >>      >
    >>      > The tests that expect an empty output  were corrected to 
    >> ignore the product version printed
    >>      > in the error stream since in some  tiers the tests are run 
    >> with ' -showversion' VM option.
    >>      >
    >>      > Testing:  Mach5 tests for tier1 - tier7 passed.
    >>      >
    >>      > [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01
    >>      > [2] https://bugs.openjdk.java.net/browse/JDK-8238561
    >>      >
    >>      > Thank you,
    >>      > Daniil
    >>      >
    >>      >
    >>
    >>
    >>
    >
    >