OpenJDK / amber / amber
changeset 60056:6bcfcb7fe83b
8235791: [TESTBUG] Fix comment in TestElfDirectRead.java
Reviewed-by: dholmes, iklam
Contributed-by: Jose Ziviani <joserz@linux.ibm.com>
author | gromero |
---|---|
date | Thu, 13 Feb 2020 16:01:46 -0500 |
parents | 02b2e4f3391f |
children | 87651cb03ebc |
files | test/hotspot/jtreg/runtime/ElfDecoder/TestElfDirectRead.java |
diffstat | 1 files changed, 4 insertions(+), 4 deletions(-) [+] |
line wrap: on
line diff
--- a/test/hotspot/jtreg/runtime/ElfDecoder/TestElfDirectRead.java Thu Feb 13 15:16:50 2020 -0500 +++ b/test/hotspot/jtreg/runtime/ElfDecoder/TestElfDirectRead.java Thu Feb 13 16:01:46 2020 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -36,10 +36,10 @@ */ // This test 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 +// with WhiteBox.disableElfSectionCache(). On platforms which do not use function +// descriptors but use instead 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 +// after one 'fseek()' call. But on platforms with function 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