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