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:
us...@infra.apache.org
