[11] RFR(S): 8207067: [test] prevent timeouts in serviceability/tmtools/jstat/{GcTest02, GcCauseTest02}.java

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Jul 12 14:51:31 UTC 2018


Hi Volker, 

I had a look at your change. 
Your intent is plausible.

Won’t it help to just set -XX:+IgnoreUnrecognizedVMOptions?

Alternatively, you could specify two test setups, one with @requires vm.debug, the 
other with !vm.debug.

If non of these are possible, your change looks good.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> bounces at openjdk.java.net] On Behalf Of David Holmes
> Sent: Donnerstag, 12. Juli 2018 01:27
> To: Volker Simonis <volker.simonis at gmail.com>; hotspot-runtime-
> dev at openjdk.java.net runtime <hotspot-runtime-dev at openjdk.java.net>
> Subject: Re: [11] RFR(S): 8207067: [test] prevent timeouts in
> serviceability/tmtools/jstat/{GcTest02, GcCauseTest02}.java
> 
> Hi Volker,
> 
> On 12/07/2018 3:30 AM, Volker Simonis wrote:
> > Hi,
> > can I please have a review for the following test fix which prevents
> > eventual test timeouts:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8207067
> > http://cr.openjdk.java.net/~simonis/webrevs/2018/8207067/
> >
> > The two tests
> hotspot/jtreg/serviceability/tmtools/jstat/{GcTest02,GcCauseTest02}.java
> > produce more than 90_000 classes until they eat up ~70% of the 128M
> > meta space they run with. The loading of each of these classes
> > triggers a full dependency check for ALL nmethods in debug/fastdebug
> > builds because 'VerifyDependencies' is 'true' there. This slows down
> > the tests from about 3 sec. in the opt build to about 88 sec. in the
> > fastdebug build on x86_64 and from about 4 sec. to about 560 sec. on
> > ppc64.
> >
> > Because the tests are not about dependency checking, it makes sense to
> > switch of 'VerifyDependencies' if they are run inside a
> > debug/fastdebug VM and decrease the execution time down to about 6
> > sec. on both x86_64 and ppc64.
> 
> It's very annoying that this can't be fixed the obvious way by just
> specifying -XX:-VerifyDependencies. Maybe jtreg could add a
> debug_only(...)  capability ... :(
> 
> It's unclear to me whether it is safe to disable VerifyDependencies
> after the VM has commenced execution. This might lead to
> inconsistencies. Probably need the compiler folk to clarify that.
> 
> That aside the comments are far too elaborate and better suited for the
> bug report. The tests could use @bug lines (though it would be nice to
> track down the original bug that added the tests). The comments could
> reduce to a simple:
> 
> // This test produces more than 90_000 classes until it eats up ~70% of
> the 128M meta space.
> // With VerifyDependencies enabled in debug builds this slows the test
> down considerably.
> // As it is a develop flag, if we see that it is "constant" then we know
> this is a product build.
> 
> Though there is already Platform.isDebugBuild() if you wanted something
> more direct. (Given you need WB to change the flag it doesn't really
> make much difference.)
> 
> Thanks,
> David
> 
> > Thank you and best regards,
> > Volker
> >


More information about the hotspot-runtime-dev mailing list