[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
nobu@ruby-lang.org wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85616] Re: Why require autoconf 2.67+
— Vít Ondruch <v.ondruch@...>
2018/02/18
VGhpcyBjb3VsZCBoZWxwIHlvdSB0byBidWlsZCBSdWJ5IHdpdGggb2xkZXIgYXV0b2NvbmYgKDIu
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
matz@ruby-lang.org wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85649] [Ruby trunk Feature#14489][Feedback] MJIT needs a reusable cache
From:
takashikkbn@...
Date:
2018-02-19 14:14:00 UTC
List:
ruby-core #85649
Issue #14489 has been updated by k0kubun (Takashi Kokubun). Status changed from Open to Feedback By the way, one thing I want to share is that currently JIT-ed function is not reusable for another process. That's because it embeds class serial that can be changed in next boot for inlining things, and pointers of ISeq / call cache that can be changed too. This ticket requires giving up some optimizations and need indirection in generated code, and it may make JIT-ed code slow. I agree that it's good to decrease time to warm up, but if it requires JIT to be slow, it doesn't make sense to me. > Also, I think https://github.com/ko1/yomikomu should be in stdlib(*) and there will be code sharing opportunity for JIT and ISeq caches. How does yomikomu.gem improve the boot time? I've thought the default way of ISeq serialization costs and bootsnap improves the performance by another way. I know bootsnap doesn't work with trunk though. ---------------------------------------- Feature #14489: MJIT needs a reusable cache https://bugs.ruby-lang.org/issues/14489#change-70441 * Author: sam.saffron (Sam Saffron) * Status: Feedback * Priority: Normal * Assignee: * Target version: ---------------------------------------- Currently on Discourse boot I notice a few minutes of jitting every time you boot it: This is a redacted output: https://gist.github.com/SamSaffron/4e18c2dacf476f1f27275f5b5d7bbb97 CPU is spinning hard compiling temp file after temp file for **minutes**: > JIT success (213.1ms): platform_string@/home/sam/.rbenv/versions/master/lib/ruby/gems/2.6.0/gems/bundler-1.16.1/lib/bundler/lazy_specification.rb:18 -> /tmp/_ruby_mjit_p6914u199.c and so on. Instead, mjit should have a reusable cache on disk it first tries fetching from prior to re-compiling. It can use an ISEQ SHA1 hash as the key to the cache. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>