2013/4/18 Olivier Lamy <ol...@apache.org> > Hi, > Could that be part of directmemory as sub project ? >
+1 or either see if there's interest in merging directly into DM (probably requiring an IP clearance). Tommaso > > 2013/4/17 serkan özal <serkanoza...@hotmail.com>: > > Project Name: Jillegal > > > > > > 1. Abstract: > > GC is one of the time taken operations in Java. GC run anytime, marks, > swaps and compacts objects at memory. If there are so many live objects, > managing them by GC leads to overhead. If objects can be allocated outside > of GC, there will be no overhead for the application. The session will go > through the new method of creating and using object off-heap with no > additional serialization/deserialization or any other overheads. > > > > > > 2. Proposal: > > For off-heap memory, I propose a solution that objects are allocated and > initialized at off-heap instead of heap. Not only object attributes are > allocated at off-heap, but also object header and metadata are allocated at > off-heap. So while a reference to this object at off-heap is being > interpreted, JVM knows which class this object references to. You can get > your off-heap object from an object pool instead of with "new" operator. > This object pool allocates a fixed size memory region from off-heap and > create empty objects with given class on there. These empty objects can be > created as lazy or eager. Another advantage off this technique is that > objects in pool are layout in memory as sequential. While accessing an > object, its neighbour objects are also fetched to CPU cache, so CPU cache > hit rate for sequential object accesses are increased. On the other hand, > freeing unused objects is responsibility of developer by calling "free" > method of object pool which means there is no dead object detection > mechanism like GC. Therefore, getting all objects from off-heap for whole > application is dangerous and not recommended. Because, this will cause > memory leaks. In addition, this technique can be combined with "Java > Instrumentation API". With "@FromOffHeap" annotation, developer can sign > classes these must be allocated from off-heap instead of heap. With "Java > Instrumentation API", all "new" operators for signed classes with > "@FromOffHeap" annotation can ben transformed to code that allocates > objects of signed class from off-heap via object pool. So developer doesn't > change all "new" keywords for getting from object pool in code. Instread of > this, just sign class with "@FromOffHeap" annotation and all "new" keywords > transformed for getting from object pool at class load time. This technique > was used at a real time CDR processing system for Turk Telekom. There were > billions of objects were used. Managing these objects by GC caused to > performance overhead. For some most used classes, we allocated these > objects from off-heap instead of "new" keyword. After some processings on > them (takes 4-5 hours), we release these allocated memory regions to > operating system by freeing them. Allocating objects from off-heap pool > helps us to gain significant execution time performance. > > > > > > 3. Rationale: > > In general, off-heap pool implementations are implemented by > serialization/deserialization to allocated off-heap memory region via > "ByteBuffer" class. But this technique leads to extra execution overhead. > Because while reading from an object, the target object must be created by > deserializing all primitive fields eagerly or only required fields on > demand and while writing to an object, the attribute has been set by > application, must be deserialized to allocated off-heap memory region. In > addition, objects itself is created at heap, so GC knows and tracks it. > With my solution, all of these overheads are overcomed. > > > > > > 4. Initial Goals: > > * Allocating objects from off-heap and using them as normal > on-heap Java object. * Allocating arrays for object types from > off-heap and using them as normal on-heap Java object arrays. * > Allocating arrays for primitive types from off-heap and using them as > normal on-heap Java primitive type arrays. * Allocating strings > from off-heap and using them as normal on-heap strings. * > Implementing auto expandable off-heap pool that expands when its delegated > off-heap pool implementation is full. * All features must be > supported for 32 bit and 64 bit JVM. * All features must be > supported for Sun HotSpot JVM, Oracle JRockit, IBM J9. > > > > 5. Currently Implemented Features: > > > > * Allocating objects from off-heap and using them as normal > on-heap Java object * Allocating arrays for object types from > off-heap and using them as normal on-heap Java object array * > Allocating arrays for primitive types from off-heap and using them as > normal on-heap Java primitive type arrays * Implementing auto > expandable off-heap pool that expands when its delegated off-heap pool > implementation is full. * All features are supported for 32 bit and > 64 bit JVM. * All features are supported for Sun HotSpot JVM, > Oracle JRockit (IBM J9 support will be added). > > > > > > 6. Roadmap > > * Automatic detection and binding for complex off-heap objects > will be implemented. * All allocated objects with new operator will > be automatically allocated from off-heap without any changing in > your code. Just annotate class whose instances must be allocated from > off-heap with "@FromOffHeap" annotation. This feature can be > implemented with Java Instrumentation API by transforming all > "new" byte codes for specified classes to a code block like > "OffHeapPool.getObject(Class clazz)" > > > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
