[jboss-jira] [JBoss JIRA] Commented: (JGRP-806) Message: investigate making the overhead for headers smaller

[Michal Frajt (JIRA)]

    [ https://jira.jboss.org/jira/browse/JGRP-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12422771#action_12422771 ] 

Michal Frajt commented on JGRP-806:
-----------------------------------

I am happy to hear that the heavy RRWL is removed from the Message class. 

Please reconsider again implementing the headers as the simple array object. The cost with the HashMap implementation is the precreation of the Entry objects when the map is initialized. Your initial capacity for the headers is currently 7. It means that the HashMap constructor precreates 7 instances of the HashMap.Entry class. The each Entry class is about 3xref (12 bytes) and one int (4 bytes) plus the Java object itself. There is the object array created for the Entries with the same length (7xref 28bytes). The HashMap has additionaly another refs and ints (~32 bytes). All together ~172 bytes within 9 java objects (another memory overhead). All the memory is required to store around ~2-4 headers for each message. The implementation using the array might take only 2 refs (8 bytes) per header. We might precreate the array for 4 headers => 4*2*4=32bytes and all as one array object only. 

There is a huge difference for the newgc (many Message instances are created/sent/received within short moment) to get rid of one 32bytes array and to get rid of ~172 bytes split into 9 objects (I suppose that many JGroups applications are using the CMS garbage collector but it should be valid on the default GC as well). The very small overhead you pay for every get/put iteration is returned at the GC time.

Next to the memory required to store the headers within the HashMap there is additionall memory required to answer the size method of the Message class. There is a hidden cost of the Map iteration where the HashMap must create a HashMap.EntrySet object for the entrySet() call return. Additionally there must be an iterator object created for every iteration within every size() method call. The total cost of using the map is than increased by another 2 objects with minimum 32 bytes data. 

Minimum garbage created by HashMap headers for 58.000 messages (sec/node)
58.000 x ((172+32b) as 11 objects) => ~12MB

Garbage created by Array headers for 58.000 messages (sec/node)
58.000 x (32 as 1 object) => ~2MB

We are able to help you with the implementation of the Message class using the array for headers. There might be only small issue with the getHeaders method which is used in dumpQueue (Util), printMessage(HDRS) and toString() from Event. We might still return a headers map copy for each call (compatibility with existing code) and create a new method getHeader(int index) for simple fast garbage-less iteration (there is already method getNumHeaders available). The three methods using getHeaders should change to the new headers iteration style.

# NEW HEADERS ITERATOR EXAMPLE 
final int headersCount = msg.getNumHeaders();
for(int i = 0; i < headersCount; ++i) {
  final Header header = msg.getHeader(i);
  ///
  ...
  ///
}

For us is very important to use API's which do not generate any non-required garbage. Over the time we have moved to the code not using even iterators to iterate over lists/sets/maps to reduce the garbage creation. We are using customized version of the GNU Trove classes for the critical parts of our applications. 

Looking forward to see new test results with the reimplemented headers!

Michal






















> Message: investigate making the overhead for headers smaller
> ------------------------------------------------------------
>
>                 Key: JGRP-806
>                 URL: https://jira.jboss.org/jira/browse/JGRP-806
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.4, 2.7
>
>
> Related to https://jira.jboss.org/jira/browse/JGRP-805.
> See whether we can make the overhead for ConcurrentHashmap in Message smaller. Potentially reduce the number of buckets for each CCHM (default: 16, IIRC). Or replace CCHMs altogether ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira