[11] RFR(S): 8206998: [test] runtime/ElfDecoder/TestElfDirectRead.java requires longer timeout on ppc64

[Lindenmaier, Goetz]

Hi David, 

I discovered this feature a while ago in 
test/hotspot/jtreg/serviceability/sa/TestUniverse.java

You get result directories with .v1 and .v2 (or the like)
appended to the directory name.

I think this is very useful, because there are a row 
of tests where several files exist to run the tests with 
different flags. The test descriptions can be moved into 
one file with this feature. E.g., 
compiler/ciReplay/TestSAClient.java
compiler/ciReplay/TestSAServer.java

Best regards,
  Goetz.


> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> bounces at openjdk.java.net] On Behalf Of David Holmes
> Sent: Dienstag, 10. Juli 2018 23:24
> 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): 8206998: [test]
> runtime/ElfDecoder/TestElfDirectRead.java requires longer timeout on
> ppc64
> 
> Hi Volker,
> 
> On 11/07/2018 3:52 AM, Volker Simonis wrote:
> > Hi,
> >
> > can I please get a review for the following test-only change:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2018/8206998/
> > https://bugs.openjdk.java.net/browse/JDK-8206998
> >
> > The problem is that the test runtime/ElfDecoder/TestElfDirectRead.java
> > intentionally disables caching of Elf sections during symbol lookup
> > with WhiteBox.disableElfSectionCache(). On platforms which do not use
> > file descriptors instead of plain function pointers this slows down
> > the lookup just a little bit, because all the symbols from an Elf file
> > are still read consecutively after one 'fseek()' call. But on
> > platforms with file descriptors like ppc64 big-endian, we get two
> > 'fseek()' calls for each symbol read from the Elf file because reading
> > the file descriptor table is nested inside the loop which reads the
> > symbols. This really trashes the I/O system and considerable slows
> > down the test, so we need an extra long timeout setting.
> >
> > The fix is trivial - simply provide two test versions (i.e. comments):
> > the first one for all Linux flavors which are not ppc64 and a second,
> > new one for Linux/ppc64 which simply has a bigger timeout.
> 
> I was not aware that this was a valid way of defining a test! This
> suggests there can only be one "leading comment" per "defining file:
> 
> http://openjdk.java.net/jtreg/tag-spec.html
> 
> Need to verify this with the jtreg folk: jtreg-use at openjdk.java.net
> 
> Thanks,
> David
> 
> > Thank you and best regards,
> > Volker
> >