[ https://issues.apache.org/jira/browse/FLINK-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735420#comment-14735420 ]
ASF GitHub Bot commented on FLINK-1320: --------------------------------------- Github user hsaputra commented on a diff in the pull request: https://github.com/apache/flink/pull/1093#discussion_r38966473 --- Diff: flink-core/src/main/java/org/apache/flink/core/memory/MemorySegmentFactory.java --- @@ -0,0 +1,135 @@ +/* + * 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.nio.ByteBuffer; + +/** + * A factory for memory segments. The purpose of this factory is to make sure that all memory segments + * for heap data are of the same type. That way, the runtime does not mix the various specializations + * of the {@link org.apache.flink.core.memory.MemorySegment}. Not mixing them has shown to be beneficial + * to method specialization by the JIT and to overall performance. + * <p> + * Note that this factory auto-initialized to use {@link org.apache.flink.core.memory.HeapMemorySegment}, + * if a request to create a segment comes before the initialization. + */ +public class MemorySegmentFactory { + + /** The factory to use */ + private static Factory factory; --- End diff -- @StephanEwen since you already merge this PR, could file JIRA to follow up on this one? Want to make sure we got this right. > Add an off-heap variant of the managed memory > --------------------------------------------- > > Key: FLINK-1320 > URL: https://issues.apache.org/jira/browse/FLINK-1320 > Project: Flink > Issue Type: Improvement > Components: Local Runtime > Reporter: Stephan Ewen > Assignee: niraj rai > Priority: Minor > > For (nearly) all memory that Flink accumulates (in the form of sort buffers, > hash tables, caching), we use a special way of representing data serialized > across a set of memory pages. The big work lies in the way the algorithms are > implemented to operate on pages, rather than on objects. > The core class for the memory is the {{MemorySegment}}, which has all methods > to set and get primitives values efficiently. It is a somewhat simpler (and > faster) variant of a HeapByteBuffer. > As such, it should be straightforward to create a version where the memory > segment is not backed by a heap byte[], but by memory allocated outside the > JVM, in a similar way as the NIO DirectByteBuffers, or the Netty direct > buffers do it. > This may have multiple advantages: > - We reduce the size of the JVM heap (garbage collected) and the number and > size of long living alive objects. For large JVM sizes, this may improve > performance quite a bit. Utilmately, we would in many cases reduce JVM size > to 1/3 to 1/2 and keep the remaining memory outside the JVM. > - We save copies when we move memory pages to disk (spilling) or through > the network (shuffling / broadcasting / forward piping) > The changes required to implement this are > - Add a {{UnmanagedMemorySegment}} that only stores the memory adress as a > long, and the segment size. It is initialized from a DirectByteBuffer. > - Allow the MemoryManager to allocate these MemorySegments, instead of the > current ones. > - Make sure that the startup script pick up the mode and configure the heap > size and the max direct memory properly. > Since the MemorySegment is probably the most performance critical class in > Flink, we must take care that we do this right. The following are critical > considerations: > - If we want both solutions (heap and off-heap) to exist side-by-side > (configurable), we must make the base MemorySegment abstract and implement > two versions (heap and off-heap). > - To get the best performance, we need to make sure that only one class > gets loaded (or at least ever used), to ensure optimal JIT de-virtualization > and inlining. > - We should carefully measure the performance of both variants. From > previous micro benchmarks, I remember that individual byte accesses in > DirectByteBuffers (off-heap) were slightly slower than on-heap, any larger > accesses were equally good or slightly better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)