Bobby Powers

And agreed on not requiring a fixed max; it is just that having a single range of virtual address space _greatly_ simplifies the implementation. I know Go does (or used...

@brano543 can you describe what actual issues you are running into? The max heap size is now 64 GB, "which ought to be enough for anybody". Please let us know...

@asl if you increase this constant here: https://github.com/plasma-umass/Mesh/blob/master/src/common.h#L104 from 64 to 2000, that should bump the max heap up to 2 TB. I would be eager to hear how this...

I'll also talk to @emeryberger - my intuition is that having a single, non-growable heap makes parts of the implementation significantly easier, but maybe I'm overthinking it.

I think this makes sense and feels like a nice, layered design. 1 thing to note @emeryberger is that we probably need to _also_ adopt the current `MiniHeap`s for not-quite-huge-but-bigger...

I confess to not being able read R code well; however when I run it under mesh what I see is: ``` Cosmic 01:37:34 {master} [bobby@cosmic-vm mesh]$ MALLOCSTATS=1 LD_PRELOAD=libmesh.so Rscript...

hi @ThreadedStream ! It sounds like it might be processor specific, but its surprising given thats a kaby lake chip. I would suggest trying to run the unit test binary...

@yongtaek-lee hi and thanks for the report! Can you confirm that you recompiled Firefox to not use jemalloc? Unfortunately, due to the Firefox build system we are not compatible with...

here is an example of disabling jemalloc in a mozbuild file: https://github.com/bpowers/mesh-artifact-firefox/blob/master/mozconfig.nojemalloc#L27

you're right in that we only support 64-bit systems right now. At a minimum, we'd need to decrease the max arena size to 2 GB here: https://github.com/plasma-umass/Mesh/blob/master/src/common.h#L98 I'm not sure...