JIT logging information needed

[Charles Oliver Nutter-2]

I have just committed a new logging setting I would appreciate JRuby on
Rails users testing out.

Last night, I added a property that limits the number of JITted methods,
to avoid filling up JVM memory and crashing the server. We have been
unable to find a leak, but we have realized we need to cap JIT to keep
the size under control.

But we do not know what a good per-runtime default limit would be. I
have arbitrarily chosen 2048 for now.

I would greatly appreciate if any Rails users that can safely do so
would update to trunk and run their apps for a good day or so with the
following properties set:

jruby.jit.max=-1  (no limit)
jruby.jit.logEvery=1000

The information I'm looking for is what kind of max number of methods
your application reaches under typical usage. Based on that, we'll
collectively try to come up with a good default.

Thank you for your help!

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Christian Seiler]

I just downloaded rev 5536 and gave it a try. When browsing around in my Rails project I get up to
about 500 compiled methods (I have no JRuby project in production yet so I don't know if all the
methods reached the compilation threshold).

I'm wondering whether the compiled code can be shared across the JRuby runtimes (I'm using Goldspike)
as I see the jruby.jit.logEvery output jumping back and forward due to the multiple runtimes.


Besided that I had to do a couple of things to get my project running with JRuby 1.1:

1) I had to tweak active_scaffold/init.rb and outcomment the invocation of install.rb. Otherwise
it will crash:

/usr/local/jruby_trunk/jruby/lib/ruby/1.8/fileutils.rb:1394:in `fu_each_src_dest': stat.st_dev unsupported on this platform (NotImplementedError)
        from /usr/local/jruby_trunk/jruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest0'
        from /usr/local/jruby_trunk/jruby/lib/ruby/1.8/fileutils.rb:1402:in `each'
        from /usr/local/jruby_trunk/jruby/lib/ruby/1.8/fileutils.rb:1402:in `fu_each_src_dest0'
        from /usr/local/jruby_trunk/jruby/lib/ruby/1.8/fileutils.rb:1402:in `fu_each_src_dest'
        from /usr/local/jruby_trunk/jruby/lib/ruby/1.8/fileutils.rb:1393:in `cp_r'
        from /usr/local/jruby_trunk/jruby/lib/ruby/1.8/fileutils.rb:422:in `copy_files'
        from /srv/rails/trunk/vendor/plugins/active_scaffold/install.rb:17
        from /srv/rails/trunk/vendor/plugins/active_scaffold/install.rb:3:in `chdir'
        from /srv/rails/trunk/vendor/plugins/active_scaffold/install.rb:3
        from /srv/rails/trunk/vendor/plugins/active_scaffold/install.rb:3:in `require'
        from /usr/local/jruby_trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from /usr/local/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `new_constants_in'
        from /usr/local/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:318:in `require'
        from /usr/local/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `eval'


Is this a known issue? That's on Ubuntu Linux, but it fails under Windows with a similar error message.


2) I had to add backport-util-concurrent.jar since this one is needed by Goldspike. JRuby 1.0 used
to have it included itself but this is no langer the case with JRuby 1.1

3) I also installed the latest version of activerecord-jdbc-adapter (0.7.1), but my custom rake task
(which starts the server) failed: Don't know how to build task 'drop'

I had to revert to 0.7.0 (though this is not related to JRuby but activerecord-jdbc)


Besides that JRuby 1.1 "feels" great, a lot smoother than 1.0.3 (at least this is my perception).

Chris

Charles Oliver Nutter-2 wrote:

I have just committed a new logging setting I would appreciate JRuby on
Rails users testing out.

Last night, I added a property that limits the number of JITted methods,
to avoid filling up JVM memory and crashing the server. We have been
unable to find a leak, but we have realized we need to cap JIT to keep
the size under control.

But we do not know what a good per-runtime default limit would be. I
have arbitrarily chosen 2048 for now.

I would greatly appreciate if any Rails users that can safely do so
would update to trunk and run their apps for a good day or so with the
following properties set:

jruby.jit.max=-1  (no limit)
jruby.jit.logEvery=1000

The information I'm looking for is what kind of max number of methods
your application reaches under typical usage. Based on that, we'll
collectively try to come up with a good default.

Thank you for your help!

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Matthew K. Williams]

I'll do so; it may be a day or so before I can set it up -- I'm going to
be presenting at codemash this week.

Matt
On Tue, 2008-01-08 at 09:27 -0800, Charles Oliver Nutter wrote:

> I have just committed a new logging setting I would appreciate JRuby on
> Rails users testing out.
>
> Last night, I added a property that limits the number of JITted methods,
> to avoid filling up JVM memory and crashing the server. We have been
> unable to find a leak, but we have realized we need to cap JIT to keep
> the size under control.
>
> But we do not know what a good per-runtime default limit would be. I
> have arbitrarily chosen 2048 for now.
>
> I would greatly appreciate if any Rails users that can safely do so
> would update to trunk and run their apps for a good day or so with the
> following properties set:
>
> jruby.jit.max=-1  (no limit)
> jruby.jit.logEvery=1000
>
> The information I'm looking for is what kind of max number of methods
> your application reaches under typical usage. Based on that, we'll
> collectively try to come up with a good default.
>
> Thank you for your help!
>
> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>

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

    http://xircles.codehaus.org/manage_email