Implementation of Concurrent::JavaSemaphore in pure Java.

[lucasallan]

@jdantonio Another good performance improvement:

# Benchmark script
require 'concurrent'
require 'benchmark'

NUM = 50_000_000

if defined? JRUBY_VERSION
  puts "~~~ JRuby version: #{JRUBY_VERSION}"

  Benchmark.bm do |stats|
    e = Concurrent::JavaSemaphore.new(NUM)

    puts "Benchmarking Concurrent::JavaSemaphore#acquire..."
    stats.report do
      NUM.times { e.acquire(1) }
    end

    e = Concurrent::JavaSemaphore.new(NUM)

    puts "Benchmarking Concurrent::JavaSemaphore#try_acquire..."
    stats.report do
      NUM.times { e.try_acquire }
    end

    e = Concurrent::JavaSemaphore.new(NUM)

    puts "Benchmarking Concurrent::JavaSemaphore#available_permits..."
    stats.report do
      NUM.times { e.available_permits }
    end
  end

end

Pure Java

~~~ JRuby version: 1.7.19
       user     system      total        real
Benchmarking Concurrent::JavaSemaphore#acquire...
  10.900000   0.070000  10.970000 ( 10.648000)
Benchmarking Concurrent::JavaSemaphore#try_acquire...
   7.420000   0.050000   7.470000 (  7.590000)
Benchmarking Concurrent::JavaSemaphore#available_permits...
   7.650000   0.110000   7.760000 (  7.982000)

JRuby

~~~ JRuby version: 1.7.19
       user     system      total        real
Benchmarking Concurrent::JavaSemaphore#acquire...
  45.410000   0.430000  45.840000 ( 46.746000)
Benchmarking Concurrent::JavaSemaphore#try_acquire...
  49.820000   0.350000  50.170000 ( 50.669000)
Benchmarking Concurrent::JavaSemaphore#available_permits...
  21.690000   0.160000  21.850000 ( 22.052000)

[jdantonio]

Wow. I'm still surprised that the performance is so different, but you can't argue with the data! 👍

[coveralls]

Coverage decreased (-5.58%) to 86.03% when pulling 381e844 on semaphore-pure-java into 9170b5b on master.

[coveralls]

Coverage increased (+0.04%) to 91.65% when pulling 381e844 on semaphore-pure-java into 9170b5b on master.

[lucasallan]

@jdantonio This one is done. I'll migrate one class at time so we can analyze them individually and easily revert if necessary. Should I merge it?

[pitr-ch]

As mentioned here #236 (comment), this should not be stored probably.

[lucasallan]

@pitr-ch Makes completely sense! I'll remove it here and I'll open a new pull request to remove the ThreadContext from JavaAtomicFixnum and JavaBooleanFixnum.

[pitr-ch]

BTW thanks for doing this!

[jdantonio]

@lucasallan Absolutely. Once the tests pass, we have some performance tests, and everyone has had a day or two to review, please feel free to merge. Thank you for taking this on!

[coveralls]

Coverage increased (+6.32%) to 91.65% when pulling 30fbf4b on semaphore-pure-java into 0c0177b on master.

[pitr-ch]

I've missed one more thing. JRuby extensions should try to use interface provided by Ruby object (result of getRuntime()) it may do additional steps like caching etc. see https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyFixnum.java#L207-L212. So it's better to use the newBoolean and newFixnum methods on Ruby object.