> For the complete documentation index, see [llms.txt](https://sliu583.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sliu583.gitbook.io/blog/specific-work/wisr-group/group/semeru-a-memory-disaggregated-managed-runtime.md).

# Semeru: A memory-disaggregated managed runtime

### Motivation 

![](/files/-MWdai4VKvv74igZ-txD)

* All resources sitting in different resource pools 
  * CPU servers: small memory
  * Memory servers: not high processing powers, handling memory accesses 
    * Today usage? 
  * Storage servers: weak core
*  Network: InfiniBand, high bandwidth 

![](/files/-MWdbaLbzXyAuDnLkGQw)

* Resource is not fully utilized 
  * This can help all the workloads to share resource better
  * Multiplex different people's workload 
* Moving towards 
  * But most cloud services are still pre-configured 

![](/files/-MWdcjXNETwKhQ4xvqSO)

* Don't understand the actual workload 
* Managed languages:
  * Program relies on language runtime (sit between user runtime and OS) to manage memory 
  * Java (objects), how these are allocated (memory), the allocated memory is not contiguous (?) digging into JVM 

![](/files/-MWddWVE8mzD6okpW0K4)

* Write something in C, manage memory allocation 
  * JVM takes care of tracing in the memory

![](/files/-MWddnJ6ZjZWAOizCfLL)

* Takes over CPU and bandwidth 

![](/files/-MWde2ee8Ijf1QYj6Uxi)

* Remote memory, two Spark applications (graph like applications) 
* Cache Ratio
  * 50%/75% goes remote 
  * No swap: best case (baseline), all accesses go locally 

![](/files/-MWdfMdb5IkA-32z4Sdp)

* GC work
  * Not much compute (suitable for memory server compute power) 
  * Data loaded locally to the memory server, cheaper 
  * Run concurrently with the program itself (not compete for resources) 

![](/files/-MWdfw5-TCZ-0VTNHH48)

![](/files/-MWdfzuDqwsQrNMY1rt3)

![](/files/-MWdgC42iwVVPBKQ4GdU)

![](/files/-MWdgFkoB1gCjk_TmRKD)

* Accessing the dirty page again? 

![](/files/-MWdgct4ax0bT-7ZAE6j)

![](/files/-MWdglOeWKLNcWSb-LMF)

* Java 
  * GC: find all objects that will never be used again 
    * E.x. variable within the loop, can be cleaned after this loop 
* Tracing is not computationally heavy 
  * Cheaper to store all tracing on local memory in memory server 

![](/files/-MWdhvmCJ-MhlNwfc3YP)

![](/files/-MWdiDL7poirQchhypqh)

![](/files/-MWdiHhp57s413euLhNB)

* Several rounds of GC: 
  * If these objects are still there, likely to remain for longer period of time
  * Java does less cleaning to older objects, and spend more times on newly-created objects 

![](/files/-MWdirfLqKVbeLjvAOO9)

![](/files/-MWdj2MsdJZKpuKFqciQ)

* Memory servers: recycling the regions of themselves 
* Data layout: reduce memory segmentation 

#### #3: how to efficiently swap data

![](/files/-MWdjPRqhjr-sO0ujZZ6)

* Control path onto different memory servers 
* Data Path
* Not interfere with each other 
* Paging:
  * Managed by the OS
  * Runtime access the page? 
    * Bypass the OS?
    * JVM has the mapping between the two 
  * Map the virtual pages in runtime to physical allocation on the memory servers 
* LegoOS:
  * this kind of disaggregated architecture 
  * Not support JVM 
  * Existing OS, then for OS, not be able to distinguish (which to handle locally, which to handle on remote). Implement this, having more flexibility. 
* Language runtime knows the program much better instead of OS 

![](/files/-MWdjb_zcV_tEw-wZ5Eb)

![](/files/-MWdnUPMqG2e0bK2grBZ)

![](/files/-MWdnsm_SnBaaw8y4F9S)

![](/files/-MWdo9titZBvLeZd5Bz0)

* JVM on disaggregated 
* GC implemented inside of JVM rather than doing this directly from the OS