You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@systemds.apache.org by GitBox <gi...@apache.org> on 2021/01/07 19:08:11 UTC

[GitHub] [systemds] philipportner opened a new pull request #1147: Unified Memory Manager design proposal

philipportner opened a new pull request #1147:
URL: https://github.com/apache/systemds/pull/1147


   Here is the design proposal for the Unified Memory Managed we discussed.
   I would greatly appreciate any feedback on stuff that I may have misunderstood.
   Also please point out any information this document should contain but is missing.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] asfgit closed pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
asfgit closed pull request #1147:
URL: https://github.com/apache/systemds/pull/1147


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] philipportner commented on pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
philipportner commented on pull request #1147:
URL: https://github.com/apache/systemds/pull/1147#issuecomment-762457895


   > Thanks @philipportner - that's a good starting point. Please incorporate the feedback and then I'll merge it in.
   
   Thanks for the feedback @mboehm7 .
   Seems like I still have some questions and added them to your comments.
   I would appreciate if you could answer them.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] mboehm7 commented on a change in pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
mboehm7 commented on a change in pull request #1147:
URL: https://github.com/apache/systemds/pull/1147#discussion_r559041581



##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |

Review comment:
       Please drop the author, we do not keep author tags in our repo, other than the github history.

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.

Review comment:
       For now, we can ignore scalar objects (e.g., stringobject) but please add frameobjects here. 

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);
+
+/**
+ * Loads the block into memory and pins it, if not evicted just pins it(?)
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block serve(String);

Review comment:
       get, and potentially merged with pin.

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);

Review comment:
       Moves the block either back to the buffer pool or drops it if it was previously not in the buffer pool.

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |

Review comment:
       The key motivation is to avoid double counting objects and avoid the unnecessary static assignment. Please rephrase this to operations min 50, buffer pool min 15, and total max 70 (every area should be able to use up to max if the workload allows).

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can

Review comment:
       If the previous Operands was referring to operations, please rename that; otherwise clarify here the 'these two'

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of

Review comment:
       unclear what this `OperandBlock` refers to. Generally, we need some form of placeholder as a reservation for pinning and allocation that will happen in operations. The pinning of inputs can be integrated once in generic primitives like `acquireRead` while the output really needs a reservation. 

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);
+
+/**
+ * Loads the block into memory and pins it, if not evicted just pins it(?)
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block serve(String);
+
+/**
+ * Reserves an specified amount in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block reserve(Size, MemoryArea);
+
+/**
+ * Resizes reserved memory in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block resize_reserved(Size, MemoryArea);

Review comment:
       drop.

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);
+
+/**
+ * Loads the block into memory and pins it, if not evicted just pins it(?)
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block serve(String);
+
+/**
+ * Reserves an specified amount in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block reserve(Size, MemoryArea);
+
+/**
+ * Resizes reserved memory in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block resize_reserved(Size, MemoryArea);
+
+```
+
+The UMM will also needs to keep track of the current state for which it will 
+have a few member variables. A queue similar to the current `EvictionQueue` is used
+to add/remove entries but rather than having a FIFO eviction policy 

Review comment:
       The EvictionQueue also supports both FIFO and LRU. 

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);
+
+/**
+ * Loads the block into memory and pins it, if not evicted just pins it(?)
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block serve(String);
+
+/**
+ * Reserves an specified amount in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block reserve(Size, MemoryArea);

Review comment:
       Reserve will always reserve in operation memory. On unpin this might then transition from operation to buffer pool memory (logically). Also the reserve cannot return a block (or do you want to have an empty matrix/frame block as a handle?). 

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);

Review comment:
       Extend: pin logically moves the given block from the buffer pool to operation memory, or adds the block to operation memory if it was not part of the buffer pool (e.g., read from hdfs).

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);
+
+/**
+ * Loads the block into memory and pins it, if not evicted just pins it(?)
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block serve(String);
+
+/**
+ * Reserves an specified amount in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block reserve(Size, MemoryArea);
+
+/**
+ * Resizes reserved memory in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block resize_reserved(Size, MemoryArea);
+
+```
+
+The UMM will also needs to keep track of the current state for which it will 
+have a few member variables. A queue similar to the current `EvictionQueue` is used
+to add/remove entries but rather than having a FIFO eviction policy 
+this queue will use LRU.
+
+
+```java
+class UMM {
+    // maximum capacity of the UMM
+    long _capacity;
+    // current operand area size
+    long _opSize;
+    // current buffer area size
+    long _bufferSize;
+    // operand block queue
+    EvictionQueue _opQueue;
+    // buffer block queue
+    EvictionQueue _bufferQueue;
+    // block handle, maybe a LocalVariableMap(?)
+    Map<String, Block> pinnedBlocks;
+}
+```
+
+
+### Block Java Class
+The first implementation will only handle CacheBlock objects, at the moment
+without any major changes to the CacheBlock object itself.
+
+If there is enough time this will be extended to an additional block type, `OperandBlock`.
+This would either require a new data type or maybe we could reuse some of the ideas
+from the `CacheableData<T extends CacheBlock> extends Data` class.

Review comment:
       If this is meant for the reservations, I don't think it would add much value and only force you to implement certain operations.

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);
+
+/**
+ * Loads the block into memory and pins it, if not evicted just pins it(?)
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block serve(String);
+
+/**
+ * Reserves an specified amount in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block reserve(Size, MemoryArea);
+
+/**
+ * Resizes reserved memory in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block resize_reserved(Size, MemoryArea);
+
+```
+
+The UMM will also needs to keep track of the current state for which it will 
+have a few member variables. A queue similar to the current `EvictionQueue` is used
+to add/remove entries but rather than having a FIFO eviction policy 
+this queue will use LRU.
+
+
+```java
+class UMM {
+    // maximum capacity of the UMM
+    long _capacity;
+    // current operand area size
+    long _opSize;
+    // current buffer area size
+    long _bufferSize;
+    // operand block queue
+    EvictionQueue _opQueue;
+    // buffer block queue
+    EvictionQueue _bufferQueue;
+    // block handle, maybe a LocalVariableMap(?)
+    Map<String, Block> pinnedBlocks;
+}
+```
+
+
+### Block Java Class
+The first implementation will only handle CacheBlock objects, at the moment
+without any major changes to the CacheBlock object itself.
+
+If there is enough time this will be extended to an additional block type, `OperandBlock`.
+This would either require a new data type or maybe we could reuse some of the ideas
+from the `CacheableData<T extends CacheBlock> extends Data` class.
+
+### Testing
+Testing will be done with the existing java based test system which runs a

Review comment:
       For this exploratory project, I would recommend to only implement the memory manager, and add component tests that uses certain sequences of interactions and checks the final state. That way you can instantiate the memory manager with a small memory budget and test everything with tiny objects.

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);

Review comment:
       Maybe combine with `resize_reserved`.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] asfgit closed pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
asfgit closed pull request #1147:
URL: https://github.com/apache/systemds/pull/1147


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] philipportner commented on a change in pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
philipportner commented on a change in pull request #1147:
URL: https://github.com/apache/systemds/pull/1147#discussion_r559781921



##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);
+
+/**
+ * Loads the block into memory and pins it, if not evicted just pins it(?)
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block serve(String);
+
+/**
+ * Reserves an specified amount in one of the two memory areas.
+ * The requested block needs to fit into UMM boundaries.
+ */
+Block reserve(Size, MemoryArea);

Review comment:
       Yes, I thought one may want the handle as soon as the memory is reserved.  If that's not the case I'll make it `void reserve(Size)`.

##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of
+operations.
+
+### UMM Java Class
+For starters, we want to keep the API rather simple.
+
+```java
+/**
+ * Pins the input block into main memory.
+ * The provided block needs to fit into UMM boundaries.
+ */
+void pin(String, Block);
+
+/**
+ * Unpins the input block from main memory.
+ */
+void unpin(String);

Review comment:
       Not quite sure how I would merge that with `resize_reserved`.
   `void unpin(String, Size)` and move the block from operation memory to the buffer pool and drop/resize if already in buffer pool?




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] mboehm7 commented on pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
mboehm7 commented on pull request #1147:
URL: https://github.com/apache/systemds/pull/1147#issuecomment-766430575


   LGTM - thanks @philipportner. Following our offline discussion, I think it's best to start bottom-up with this very central component. So for now we focus purely on the cache blocks and implement and test the memory manager in a component-local manner without considering the surrounding meta data objects (CacheableData). 
   
   I now converted you design document to a java class with the design as java doc and a reworked API that should cover the main use cases and clarify the individual API interactions and state transitions. Looking forward to your initial implementation.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] philipportner commented on a change in pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
philipportner commented on a change in pull request #1147:
URL: https://github.com/apache/systemds/pull/1147#discussion_r559782106



##########
File path: scripts/staging/unified-memory-manager/umm.md
##########
@@ -0,0 +1,144 @@
+<!--
+{% comment %}
+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.
+{% end comment %}
+-->
+
+# Unified Memory Manager - Design Document
+
+| **Author(s)** | Philipp Ortner |
+:-------------- |:----------------------------------------------------|
+
+## Description
+This document describes the initial design of an Unified Memory Manager proposed
+for SystemDS.
+
+## Design
+The Unified Memory Manager, henceforth UMM, will act as a manager for heap memory
+provided by the JVM.
+
+The UMM has a certain (% of JVM heap) amount of memory which it can distribute for operands
+and a buffer pool.
+
+Operands are the compiled programs variables which extends the base class 
+`Data`, e.g., `MatrixObject` and `StringObject`.
+The buffer pool manages
+in memory representation of dirty objects that don't exist on the HDFS or 
+other persistent memory. This is currently done by the `LazyWriteBuffer`. Intermediates
+could be represented in this buffer.
+
+These two memory areas each will have a min and max amount of memory it can
+occupy, meaning that the boundary for the areas can shift dynamically depending
+on the current load.
+
+||min|max|
+| ------------- |:-------------:| -----:|
+| operations  | 50% | 70% |
+| buffer pool | 15% | 30% |
+
+The UMM will utilise the existing `CacheBlock` structure to manage the buffer
+pool area while it will use the new `OperandBlock (?)` structure to keep track of

Review comment:
       I may be using the terminology wrong, I actually meant what you described.
   
   I looked through the code again and I think I'm missing something.
   
   The `MatrixObject`, `FrameObject` and the `TensorObject` implement the `CacheBlock` interface.
   The `LazyWriteBuffer` itself seems to manage `ByteBuffer` instances, which in turn also hold `CacheBlocks`, at least for dense data.
   
   Could you please elaborate again on a few things I seem to not be 100% clear about.
   1) Which current classes do you mean when you talk about operation memory?
   2) Which classes are we talking about when you mean intermediates / dirty objects that are supposed to go into the buffer pool area?
   
   I'll try to answer them myself, maybe you can correct me.
   ad1) As mentioned in the design document, derivatives of `Data` like `MatrixObject`, `FrameObject` and `TensorObject`.
   ad2) Here I'm not sure, looking at the code I would say these are also `CacheableData` objects, for example in the `ExecutionContext` or `EstimatorDensityMap`, these are working with `MatrixBlocks`, which ultimately is also a `CacheBlock`. Only dense data, e.g., `DenseBlock` instances do not hold `CacheBlock`.
   
   It kinda feels like I'm missing something, we said the second `Block` does not exist currently but it looks like the `CacheBlock` would suffice. In that case the split memory area would just be a logical differentiation.
   




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [systemds] mboehm7 commented on pull request #1147: Unified Memory Manager design proposal

Posted by GitBox <gi...@apache.org>.
mboehm7 commented on pull request #1147:
URL: https://github.com/apache/systemds/pull/1147#issuecomment-766430575


   LGTM - thanks @philipportner. Following our offline discussion, I think it's best to start bottom-up with this very central component. So for now we focus purely on the cache blocks and implement and test the memory manager in a component-local manner without considering the surrounding meta data objects (CacheableData). 
   
   I now converted you design document to a java class with the design as java doc and a reworked API that should cover the main use cases and clarify the individual API interactions and state transitions. Looking forward to your initial implementation.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org