Skip to content

Home

Jump to bottom
feiben edited this page Dec 10, 2015 · 4 revisions

Welcome to the LunarMax wiki!

Big data in real time, you really do not want to:

  1. Stop-the-World Garbage Collection. Java brings high pruductivity, but the GC is a pain in runtime.

  2. Real time computation need big memory, but heap memory provided by JVM is far from enough. And bigger heap equals to a long time GC.

  3. Java programmer has no privilege to control the memory. All you can do is a bunch of tricky JVM parameters to tune. But in many cases, you really need to control.

  4. As normal c/c++ programs, frequently alloc/free operations generates tones of memory fragments. The longer running, the slower of allocation.

  5. Then we need an enterprise-level memory solution, enable java programmers to control direct memory, providing constant allocation time and no fragment produced.

You should use Java Direct Buffer to get a bigger off-heap memory. But LunarMax can do much more for you:

  1. No memory fragments will be generated. LunarMax has an internal light weighted GC thread, to clean up small pieces of memories, which is essential for a long-time on-line service. If we use new/delete or malloc/free, after millions of times of operations, the memory allocation becomes slow with a great number of fragments generated.

  2. Java do not permit us to release the object memory that allocated. GC responds to it. But we don't want the "stop the world" job.

  3. To simplify the deployment. We do not have our clients deploy an extra cache solution for hot data, the server environment should be simple.

  4. According to our test, LunarMax allocates/frees memory 3 times faster than default new/delete solution. The longer it runs, the faster it will be comparing to the slowing down new/delete.

5 LunarMax has an internal memory index, searchable for your keys. In other words, it is a memory k-v database, with capability of managing TB in memory data.

Clone this wiki locally