Re: Reducing JRuby memory footprint

Ruby JRuby
1

This is most likely due to instantiating a concurrenthashmap with the
default setting for the concurrencyLevel.

Internally the map shards the data, and the # of shards is relative to
the
concurrency level. The default value is 16 and it 98.2342% of the cases
that is probably overkill and will eat up memory i.e. 16 threads hitting
your hashmap is unlikely

Hopefully the JRuby committers can look into this issue if it is indeed
the
case…

2

Hi Salman,

On 21/03/12 13:48, Salman Ahmed wrote:

This is most likely due to instantiating a concurrenthashmap with the
default setting for the concurrencyLevel.

Internally the map shards the data, and the # of shards is relative to
the concurrency level. The default value is 16 and it 98.2342% of the
cases that is probably overkill and will eat up memory i.e. 16 threads
hitting your hashmap is unlikely

Well… I am using a single threaded container, so I guess the
probability of more than one thread hitting the hash map is zero (?) :wink:

But for concurrent containers, this mboi:

The JDK8 CHM (which is more memory efficient) is available in the JSR
repo
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ConcurrentHashMapV8.java?revision=1.37&view=markup
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ConcurrentHashMapV8.java?revision=1.37&view=markup

For example, the infinispan guys have backported it
http://java.dzone.com/articles/jdk-8-backported

I've been doing some stress testing in my project (vert.x). If
thousands of JRuby deployments.

Since I have chosen the scripting container to be single threaded,


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

–
Tim F.

Vert.x - effortless polyglot asynchronous application development

twitter:@timfox