<feed xmlns='http://www.w3.org/2005/Atom'>
<title>ruby.git/yjit/bindgen/src/main.rs, branch v3_2_11</title>
<subtitle>The Ruby Programming Language</subtitle>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/'/>
<entry>
<title>merge revision(s) 3b83b265f11965582d4b9b439eff8a501792ab68: [Backport #19404]</title>
<updated>2023-02-06T05:00:47+00:00</updated>
<author>
<name>NARUSE, Yui</name>
<email>naruse@airemix.jp</email>
</author>
<published>2023-02-06T05:00:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=3a88589399f7f1059be245f766809c49790ad939'/>
<id>3a88589399f7f1059be245f766809c49790ad939</id>
<content type='text'>
	YJIT: Crash with rb_bug() when panicking

	Helps with getting good bug reports in the wild. Intended to be
	backported to the 3.2.x series.
	---
	 yjit/bindgen/src/main.rs       |  3 +++
	 yjit/src/cruby_bindings.inc.rs |  1 +
	 yjit/src/yjit.rs               | 29 +++++++++++++++++++++++++++--
	 3 files changed, 31 insertions(+), 2 deletions(-)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
	YJIT: Crash with rb_bug() when panicking

	Helps with getting good bug reports in the wild. Intended to be
	backported to the 3.2.x series.
	---
	 yjit/bindgen/src/main.rs       |  3 +++
	 yjit/src/cruby_bindings.inc.rs |  1 +
	 yjit/src/yjit.rs               | 29 +++++++++++++++++++++++++++--
	 3 files changed, 31 insertions(+), 2 deletions(-)
</pre>
</div>
</content>
</entry>
<entry>
<title>Transition complex objects to "too complex" shape</title>
<updated>2022-12-15T18:06:04+00:00</updated>
<author>
<name>Jemma Issroff</name>
<email>jemmaissroff@gmail.com</email>
</author>
<published>2022-12-08T22:16:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=c1ab6ddc9a6fa228caa5d26b118b54855051279c'/>
<id>c1ab6ddc9a6fa228caa5d26b118b54855051279c</id>
<content type='text'>
When an object becomes "too complex" (in other words it has too many
variations in the shape tree), we transition it to use a "too complex"
shape and use a hash for storing instance variables.

Without this patch, there were rare cases where shape tree growth could
"explode" and cause performance degradation on what would otherwise have
been cached fast paths.

This patch puts a limit on shape tree growth, and gracefully degrades in
the rare case where there could be a factorial growth in the shape tree.

For example:

```ruby
class NG; end

HUGE_NUMBER.times do
  NG.new.instance_variable_set(:"@unique_ivar_#{_1}", 1)
end
```

We consider objects to be "too complex" when the object's class has more
than SHAPE_MAX_VARIATIONS (currently 8) leaf nodes in the shape tree and
the object introduces a new variation (a new leaf node) associated with
that class.

For example, new variations on instances of the following class would be
considered "too complex" because those instances create more than 8
leaves in the shape tree:

```ruby
class Foo; end
9.times { Foo.new.instance_variable_set(":@uniq_#{_1}", 1) }
```

However, the following class is *not* too complex because it only has
one leaf in the shape tree:

```ruby
class Foo
  def initialize
    @a = @b = @c = @d = @e = @f = @g = @h = @i = nil
  end
end
9.times { Foo.new }
``

This case is rare, so we don't expect this change to impact performance
of most applications, but it needs to be handled.

Co-Authored-By: Aaron Patterson &lt;tenderlove@ruby-lang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When an object becomes "too complex" (in other words it has too many
variations in the shape tree), we transition it to use a "too complex"
shape and use a hash for storing instance variables.

Without this patch, there were rare cases where shape tree growth could
"explode" and cause performance degradation on what would otherwise have
been cached fast paths.

This patch puts a limit on shape tree growth, and gracefully degrades in
the rare case where there could be a factorial growth in the shape tree.

For example:

```ruby
class NG; end

HUGE_NUMBER.times do
  NG.new.instance_variable_set(:"@unique_ivar_#{_1}", 1)
end
```

We consider objects to be "too complex" when the object's class has more
than SHAPE_MAX_VARIATIONS (currently 8) leaf nodes in the shape tree and
the object introduces a new variation (a new leaf node) associated with
that class.

For example, new variations on instances of the following class would be
considered "too complex" because those instances create more than 8
leaves in the shape tree:

```ruby
class Foo; end
9.times { Foo.new.instance_variable_set(":@uniq_#{_1}", 1) }
```

However, the following class is *not* too complex because it only has
one leaf in the shape tree:

```ruby
class Foo
  def initialize
    @a = @b = @c = @d = @e = @f = @g = @h = @i = nil
  end
end
9.times { Foo.new }
``

This case is rare, so we don't expect this change to impact performance
of most applications, but it needs to be handled.

Co-Authored-By: Aaron Patterson &lt;tenderlove@ruby-lang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>YJIT: Upgrade bindgen to stabilize and reduce output</title>
<updated>2022-12-08T22:35:18+00:00</updated>
<author>
<name>Alan Wu</name>
<email>XrXr@users.noreply.github.com</email>
</author>
<published>2022-12-08T20:03:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=e714907d82f486c13fc1ea5e3ad291dabf4e7fbe'/>
<id>e714907d82f486c13fc1ea5e3ad291dabf4e7fbe</id>
<content type='text'>
The new version has an option to merge everything into a big
`extern "C"` block and it's nicer.

More importantly, this upgrade fixes an issue where Ubuntu with Clang 12
and macOS with Clang 14 gave a one line diff for `rb_shape_t`. It was
slightly annoying because we use macOS locally.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The new version has an option to merge everything into a big
`extern "C"` block and it's nicer.

More importantly, this upgrade fixes an issue where Ubuntu with Clang 12
and macOS with Clang 14 gave a one line diff for `rb_shape_t`. It was
slightly annoying because we use macOS locally.
</pre>
</div>
</content>
</entry>
<entry>
<title>YJIT: Extract SHAPE_ID_NUM_BITS into a constant (#6863)</title>
<updated>2022-12-05T21:20:11+00:00</updated>
<author>
<name>Jemma Issroff</name>
<email>jemmaissroff@gmail.com</email>
</author>
<published>2022-12-05T21:20:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=e7642d8095d7f597c322ed26797d649aec7edbd9'/>
<id>e7642d8095d7f597c322ed26797d649aec7edbd9</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove unused rb_shape_flag_shift and rb_shape_flag_mask</title>
<updated>2022-12-02T20:53:51+00:00</updated>
<author>
<name>Jemma Issroff</name>
<email>jemmaissroff@gmail.com</email>
</author>
<published>2022-12-02T18:41:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=41bacd9b0d0a2cec497b0b81c0d5916c5e98e96f'/>
<id>41bacd9b0d0a2cec497b0b81c0d5916c5e98e96f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Extracted rb_shape_id_offset</title>
<updated>2022-12-02T20:53:51+00:00</updated>
<author>
<name>Jemma Issroff</name>
<email>jemmaissroff@gmail.com</email>
</author>
<published>2022-12-02T17:33:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=4c5e89791b2e5e168aadb949c90f804736a472bd'/>
<id>4c5e89791b2e5e168aadb949c90f804736a472bd</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>bail on compilation if the comptime receiver is frozen</title>
<updated>2022-12-02T20:53:51+00:00</updated>
<author>
<name>Aaron Patterson</name>
<email>tenderlove@ruby-lang.org</email>
</author>
<published>2022-11-17T00:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=744b0527eacb6f1d76c225c720c1a3ed23185ad4'/>
<id>744b0527eacb6f1d76c225c720c1a3ed23185ad4</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>implement IV writes</title>
<updated>2022-12-02T20:53:51+00:00</updated>
<author>
<name>Aaron Patterson</name>
<email>tenderlove@ruby-lang.org</email>
</author>
<published>2022-11-16T23:37:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=17f9bcd7d77c0d9fdd4be605f0791f3f03fd6caf'/>
<id>17f9bcd7d77c0d9fdd4be605f0791f3f03fd6caf</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>YJIT: Make case-when optimization respect === redefinition (#6846)</title>
<updated>2022-12-02T16:40:16+00:00</updated>
<author>
<name>Alan Wu</name>
<email>XrXr@users.noreply.github.com</email>
</author>
<published>2022-12-02T16:40:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=eb2b717a8bfc18f8ee53ff3d738bcfd3960f8fa4'/>
<id>eb2b717a8bfc18f8ee53ff3d738bcfd3960f8fa4</id>
<content type='text'>
* YJIT: Make case-when optimization respect === redefinition

Even when a fixnum key is in the dispatch hash, if there is a case such
that its basic operations for === is redefined, we need to fall back to
checking each case like the interpreter. Semantically we're always
checking each case by calling === in order, it's just that this is not
observable when basic operations are intact.

When all the keys are fixnums, though, we can do the optimization we're
doing right now. Check for this condition.

* Update yjit/src/cruby_bindings.inc.rs

Co-authored-by: Takashi Kokubun &lt;takashikkbn@gmail.com&gt;

Co-authored-by: Takashi Kokubun &lt;takashikkbn@gmail.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* YJIT: Make case-when optimization respect === redefinition

Even when a fixnum key is in the dispatch hash, if there is a case such
that its basic operations for === is redefined, we need to fall back to
checking each case like the interpreter. Semantically we're always
checking each case by calling === in order, it's just that this is not
observable when basic operations are intact.

When all the keys are fixnums, though, we can do the optimization we're
doing right now. Check for this condition.

* Update yjit/src/cruby_bindings.inc.rs

Co-authored-by: Takashi Kokubun &lt;takashikkbn@gmail.com&gt;

Co-authored-by: Takashi Kokubun &lt;takashikkbn@gmail.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>YJIT: Reorder branches for Fixnum opt_case_dispatch (#6841)</title>
<updated>2022-12-01T15:59:56+00:00</updated>
<author>
<name>Takashi Kokubun</name>
<email>takashikkbn@gmail.com</email>
</author>
<published>2022-12-01T15:59:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=2c939458cab06b4fda09b55a57b8bac30efe6b17'/>
<id>2c939458cab06b4fda09b55a57b8bac30efe6b17</id>
<content type='text'>
* YJIT: Reorder branches for Fixnum opt_case_dispatch

Co-authored-by: Maxime Chevalier-Boisvert &lt;maxime.chevalierboisvert@shopify.com&gt;
Co-authored-by: Alan Wu &lt;alansi.xingwu@shopify.com&gt;

* YJIT: Don't support too large values

Co-authored-by: Maxime Chevalier-Boisvert &lt;maxime.chevalierboisvert@shopify.com&gt;
Co-authored-by: Alan Wu &lt;alansi.xingwu@shopify.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* YJIT: Reorder branches for Fixnum opt_case_dispatch

Co-authored-by: Maxime Chevalier-Boisvert &lt;maxime.chevalierboisvert@shopify.com&gt;
Co-authored-by: Alan Wu &lt;alansi.xingwu@shopify.com&gt;

* YJIT: Don't support too large values

Co-authored-by: Maxime Chevalier-Boisvert &lt;maxime.chevalierboisvert@shopify.com&gt;
Co-authored-by: Alan Wu &lt;alansi.xingwu@shopify.com&gt;</pre>
</div>
</content>
</entry>
</feed>
