This is an automated email from the ASF dual-hosted git repository.

gurwls223 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/spark.git


The following commit(s) were added to refs/heads/master by this push:
     new a77505d  [CORE][MINOR] Fix some typos about MemoryMode
a77505d is described below

commit a77505d4d3e5db4413d7fa76610265792d949c64
Author: SongYadong <song.yado...@zte.com.cn>
AuthorDate: Tue Jan 15 14:40:00 2019 +0800

    [CORE][MINOR] Fix some typos about MemoryMode
    
    ## What changes were proposed in this pull request?
    
    Fix typos in comments by replacing "in-heap" with "on-heap".
    
    ## How was this patch tested?
    
    Existing Tests.
    
    Closes #23533 from SongYadong/typos_inheap_to_onheap.
    
    Authored-by: SongYadong <song.yado...@zte.com.cn>
    Signed-off-by: Hyukjin Kwon <gurwls...@apache.org>
---
 .../src/main/java/org/apache/spark/unsafe/array/LongArray.java      | 2 +-
 .../main/java/org/apache/spark/unsafe/memory/MemoryLocation.java    | 2 +-
 core/src/main/java/org/apache/spark/memory/TaskMemoryManager.java   | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/common/unsafe/src/main/java/org/apache/spark/unsafe/array/LongArray.java 
b/common/unsafe/src/main/java/org/apache/spark/unsafe/array/LongArray.java
index 2cd39bd..305cc1c 100644
--- a/common/unsafe/src/main/java/org/apache/spark/unsafe/array/LongArray.java
+++ b/common/unsafe/src/main/java/org/apache/spark/unsafe/array/LongArray.java
@@ -23,7 +23,7 @@ import org.apache.spark.unsafe.memory.MemoryBlock;
 /**
  * An array of long values. Compared with native JVM arrays, this:
  * <ul>
- *   <li>supports using both in-heap and off-heap memory</li>
+ *   <li>supports using both on-heap and off-heap memory</li>
  *   <li>has no bound checking, and thus can crash the JVM process when assert 
is turned off</li>
  * </ul>
  */
diff --git 
a/common/unsafe/src/main/java/org/apache/spark/unsafe/memory/MemoryLocation.java
 
b/common/unsafe/src/main/java/org/apache/spark/unsafe/memory/MemoryLocation.java
index 74ebc87..897b8a2 100644
--- 
a/common/unsafe/src/main/java/org/apache/spark/unsafe/memory/MemoryLocation.java
+++ 
b/common/unsafe/src/main/java/org/apache/spark/unsafe/memory/MemoryLocation.java
@@ -21,7 +21,7 @@ import javax.annotation.Nullable;
 
 /**
  * A memory location. Tracked either by a memory address (with off-heap 
allocation),
- * or by an offset from a JVM object (in-heap allocation).
+ * or by an offset from a JVM object (on-heap allocation).
  */
 public class MemoryLocation {
 
diff --git a/core/src/main/java/org/apache/spark/memory/TaskMemoryManager.java 
b/core/src/main/java/org/apache/spark/memory/TaskMemoryManager.java
index 28b646b..1d93918 100644
--- a/core/src/main/java/org/apache/spark/memory/TaskMemoryManager.java
+++ b/core/src/main/java/org/apache/spark/memory/TaskMemoryManager.java
@@ -85,9 +85,9 @@ public class TaskMemoryManager {
   /**
    * Similar to an operating system's page table, this array maps page numbers 
into base object
    * pointers, allowing us to translate between the hashtable's internal 
64-bit address
-   * representation and the baseObject+offset representation which we use to 
support both in- and
+   * representation and the baseObject+offset representation which we use to 
support both on- and
    * off-heap addresses. When using an off-heap allocator, every entry in this 
map will be `null`.
-   * When using an in-heap allocator, the entries in this map will point to 
pages' base objects.
+   * When using an on-heap allocator, the entries in this map will point to 
pages' base objects.
    * Entries are added to this map as new data pages are allocated.
    */
   private final MemoryBlock[] pageTable = new MemoryBlock[PAGE_TABLE_SIZE];
@@ -102,7 +102,7 @@ public class TaskMemoryManager {
   private final long taskAttemptId;
 
   /**
-   * Tracks whether we're in-heap or off-heap. For off-heap, we short-circuit 
most of these methods
+   * Tracks whether we're on-heap or off-heap. For off-heap, we short-circuit 
most of these methods
    * without doing any masking or lookups. Since this branching should be 
well-predicted by the JIT,
    * this extra layer of indirection / abstraction hopefully shouldn't be too 
expensive.
    */


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@spark.apache.org
For additional commands, e-mail: commits-h...@spark.apache.org

Reply via email to