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

Jonathan Gibbons jonathan.gibbons at oracle.com
Mon Jul 23 21:48:10 UTC 2018


Volker,

Sorry I missed this before my recent vacation.

Yes, it is now "officially" supported that you can have multiple test 
descriptions (comment blocks beginning '@test').

Since forever, it was unofficially allowed but not well integrated as a 
feature. This was fixed a while back:

7901940: support multiple @test in one test file

The issue which needed to be fixed was in the naming of the individual 
tests within the file, such that you could distinguish the individual 
tests from the overall collection of tests in the file.

-- Jon

On 7/11/18 12:34 AM, Volker Simonis wrote:
> Hi David,
>
> so it obviously works and as Goetz mentioned there are already other,
> existing tests which use this feature.
>
> Do you want me to get a formal review which confirms this from
> somebody from the JTreg team?
>
> I've CC-ed jtreg-use and Jonathan in the hope that they can confirm this.
>
> Regards,
> Volker
>
> On Tue, Jul 10, 2018 at 11:24 PM, David Holmes <david.holmes at oracle.com> wrote:
>> 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
>>>



More information about the hotspot-runtime-dev mailing list