Thanks for that Charlie, looks interesting.
Before anyone gets into that, what about the other candidates. I know of at
least 2:
* Doug Lea's ConcurrentHashMapV8
* Cliff Click's ConcurrentHashMap -
http://high-scale-lib.cvs.sourceforge.net/viewvc/high-scale-lib/high-scale-lib/java/util/concurrent
Uwe Kubosch created JRUBY-6297:
--
Summary: SIGSEGV running application with Java 7u2 and master
Key: JRUBY-6297
URL: https://jira.codehaus.org/browse/JRUBY-6297
Project: JRuby
Issue Type: Bug
Ok, so I thought I was really clever when I did this to fix the
repeated .extend of WaitReadable into EAGAIN exceptions...
https://github.com/jruby/jruby/commit/21ea42097e
Unfortunately, this appears to break either stdlib (net/protocol) or
RubyGems or some combination of the two. I'm looking for
Karl Baum created JRUBY-6298:
Summary: Error trying to build head of jruby with rvm against java
1.7
Key: JRUBY-6298
URL: https://jira.codehaus.org/browse/JRUBY-6298
Project: JRuby
Issue Type: B
On 2011-12-20, at 07:19, Charles Oliver Nutter wrote:
> I was thinking of bumping to 1GB.
>
> A 32-bit JVM can't go higher than a 4GB process space, and typically
> you don't go above 2GB heap there in case there's a lot of native
> memory that might push it close to the 32-bit process limit. So
JVM ergonomics can default to a very small (64Mb) max heap on 32-bit
desktop-class systems; at least older JVMs certainly used to. That's not
enough to do very much at all.
It would be nice to just yield to the JVM's ergonomics when it is doing
something useful, like the allocations 1.5 and up hav
I have thought about this in the past.
The problem is that there's no way to know what settings the JVM will
use (or supports) without launching the JVM. I have toyed with the
idea of doing a separate execution of 'java' just to get information
on the JVM, either on every startup (for just base JV
Charles Oliver Nutter created JRUBY-6299:
Summary: Slow perf in String#split or #join on 1.9 mode
Key: JRUBY-6299
URL: https://jira.codehaus.org/browse/JRUBY-6299
Project: JRuby
Issue
