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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Volker Simonis
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 <[hidden email]> 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: [hidden email]
>
> Thanks,
> David
>
>
>> Thank you and best regards,
>> Volker
>>
>
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
Hi Volker,

On 11/07/2018 5:34 PM, 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.

No that's fine - just surprised to see this (and couldn't find any
documentation for it!).

Thanks,
David

> Regards,
> Volker
>
> On Tue, Jul 10, 2018 at 11:24 PM, David Holmes <[hidden email]> 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: [hidden email]
>>
>> Thanks,
>> David
>>
>>
>>> Thank you and best regards,
>>> Volker
>>>
>>