Github user uce commented on a diff in the pull request:
https://github.com/apache/flink/pull/290#discussion_r22651835
--- Diff:
flink-core/src/main/java/org/apache/flink/core/memory/DirectMemorySegment.java
---
@@ -0,0 +1,560 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.flink.core.memory;
+
+import java.io.DataInput;
+import java.io.DataOutput;
+import java.io.IOException;
+import java.lang.reflect.Field;
+import java.nio.BufferOverflowException;
+import java.nio.BufferUnderflowException;
+import java.nio.ByteBuffer;
+
+/**
+ * This class uses in parts code from Java's direct byte buffer API.
+ *
+ * The use in this class two crucial additions:
+ * - It uses collapsed checks for range check and memory segment disposal.
+ * - It offers absolute positioning methods for byte array put/get
methods, to guarantee thread safe use.
+ *
+ * In addition, the code that uses this class should make sure that only
one implementation class is ever loaded -
+ * Either the {@link HeapMemorySegment}, or this DirectMemorySegment. That
way, all the abstract methods in the
+ * MemorySegment base class have only one loaded actual implementation.
This is easy for the JIT to recognize through
+ * class hierarchy analysis, or by identifying that the invocations are
monomorphic (all go to the same concrete
+ * method implementation). Under this precondition, the JIT can perfectly
inline methods.
+ *
+ * This is harder to do and control with byte buffers, where different
code paths use different versions of the class
+ * (heap, direct, mapped) and thus virtual method invocations are
polymorphic and are not as easily inlined.
+ */
+public class DirectMemorySegment extends MemorySegment {
+
+ /** The direct byte buffer that allocated the memory */
+ protected final ByteBuffer buffer;
+
+ /** The address to the off-heap data */
+ private long address;
+
+ /** The address one byte after the last addressable byte.
+ * This is address + size while the segment is not disposed */
+ private final long addressLimit;
+
+ /** The size in bytes of the memory segment */
+ private final int size;
+
+ //
-------------------------------------------------------------------------
+ // Constructors
+ //
-------------------------------------------------------------------------
+
+ public DirectMemorySegment(int size) {
+ this(ByteBuffer.allocateDirect(size));
+ }
+
+ public DirectMemorySegment(ByteBuffer buffer) {
+ if (buffer == null || !buffer.isDirect()) {
+ throw new IllegalArgumentException();
+ }
+
+ this.buffer = buffer;
+ this.size = buffer.capacity();
+ this.address = getAddress(buffer);
+ this.addressLimit = this.address + size;
+
+ if (address >= Long.MAX_VALUE - Integer.MAX_VALUE) {
+ throw new RuntimeException("Segment initialized with
too large address: " + address);
--- End diff --
OK. Makes sense now :) I didn't see the index/free check before.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
