MemoryManager
APIs
NanoSparqlServer
REST API
JAVA Client API
Client Libraries
Notes on compliance with the Sesame API
Apache Tinkerpop 3
Using Blueprints with Blazegraph
Blazegraph FAQ
Sample Applications
Sesame API embedded mode
Sesame API remote mode
Blueprints API embedded mode
Blueprints API remote mode
RDR
SPARQL Extensions
Full Text Search
External Full Text Search
GeoSpatial Search
Analytic Query
Virtual Graphs
Query Hints
Named Subquery
SPARQL Update
Federated Query
Stored Query
Property Paths
Custom Function
InlineIVs
Linked Data
Inference and Truth Maintenance
Reification Done Right
Graph Mining
RDF GAS API
Optimizations and Benchmarking
Performance Optimization
IO Optimization
Query Optimization
Using Explain
SPARQL Benchmarks
Deeper Background
Standalone Guide
BTree Guide
Tx Guide
Striterators
RWStore
Memory Manager
Retention History
Unicode
Developers
Maven Repository
Client Libraries
Sesame API Compliance
Maven Notes
Code Examples
Submitting Bugs
Contributors
ReleaseGuide
Javadoc/API
Common Problems
Operations procedures
Data Migration
Bulk Data Load
Rebuilding the Text Index
Hardware Configuration
Clone this wiki locally
Memory Manager
The MemoryManager provides 100% Java RWStore-like technology for the native JVM process heap. Allocations are made using java.nio.ByteBuffer.allocateDirect() and are managed using a pool of direct buffers. The MemoryManager can manage up to 4TB of main memory with ZERO GC overhead.
Motivation
Due to byte code optimization, Java applications can run as fast as hand coded C application. However, there is a hidden cost associated with Java application — the maintenance of the JVM object heap. For many applications the cost of object creation, retention, and garbage collection may be negligible. However, as illustrated in the diagram below, an application with a high object creation and retention rate can get into trouble with the Garbage Collector.
As the application induced “heap pressure” increases, the garbage collector must run more and more frequently. Depending on the mode in which the garbage collector is running, it may either take cores away from the application or freeze out the application entirely during GC cycles. As the application heap pressure increases, the GC cycle time increases as well. Eventually, the garbage collector runs more than the application and application throughput plummets. Larger heaps can only mask this problem temporarily since larger heaps require more GC time.
The MemoryManager provides a basis for highly scalable Java application which would otherwise be swamped by excessive heap pressure.