[#46309] [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX — "usa (Usaku NAKAMURA)" <usa@...>

13 messages 2012/10/29
[#46310] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX — Tanaka Akira <akr@...> 2012/10/29

2012年10月29日 10:31 usa (Usaku NAKAMURA) <[email protected]>:

[#46366] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX — "U.Nakamura" <usa@...> 2012/11/02

こんにちは、なかむら(う)です。

[#46375] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX — KOSAKI Motohiro <kosaki.motohiro@...> 2012/11/02

>> とくに指定しなければ、default external は locale から設定されるので、

[ruby-dev:46186] Re: [ruby-trunk - Bug #7095][Open] Non-recursive marking

From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2012-10-01 18:00:36 UTC
List: ruby-dev #46186
2012/10/1 SASADA Koichi <[email protected]>:
> (2012/10/02 0:21), authorNari (Narihiro Nakamura) wrote:
>>
>> Issue #7095 has been reported by authorNari (Narihiro Nakamura).
>>
>> ----------------------------------------
>> Bug #7095: Non-recursive marking
>> https://bugs.ruby-lang.org/issues/7095
>>
>> Author: authorNari (Narihiro Nakamura)
>> Status: Open
>> Priority: Normal
>> Assignee: authorNari (Narihiro Nakamura)
>> Category: core
>> Target version: 2.0.0
>> ruby -v: ruby 2.0.0dev (2012-09-25 trunk 37032) [x86_64-linux]
>>
>>
>> nariです。
>>
>> GCのマーキングで関数の再帰呼び出しを使わないバージョンを書いてみました。
>>
>> 差分: https://github.com/authorNari/ruby/compare/non_recursion_marking
>> パッチ: https://github.com/authorNari/ruby/compare/non_recursion_marking.patch
>>
>> = 現状の問題点
>> 現在のマークは、基本的にはオブジェクト、子オブジェクト、孫オブジェクト
>> と、gc_mark()を再帰的に呼び出すという実装になっています。
>> もしもオブジェクトがすごく深いグラフを持っていた場合にはマシンスタック
>> が溢れてしまうので、GCが「あ、スタックが溢れそう」と判断するとそれ以上
>> はマシンスタックを使わない方法でマークを行おうとします。
>
> +1

+100 ぐらい入れたいんだけど、一人一票なんだっけ?


> 遅くなっていない,ということで,デメリットが思いつかないのでよろしいの
> じゃないかと思います.素晴らしい(パッチあんまり真面目に読んでないけど).
>
>
> あまり本質じゃないんですが,
> - page という言葉は適当でしょうか.

なんか page size が 4kと決めうって逆算されているような・・・
mallocを使っているのでページサイズより小さくても悪影響あんまりでそうにないけど


> - GC の度に毎回 malloc? いいんだっけ.最初の1ページは最初に alloc する
> からいいのかな.

二度とfreeしない戦略とかじゃダメなのかなーとか思いました。もしくはmarkのときにスタックを半分以下しか使わなかったら1ページだけ解放するとかにして動的に長さが調整されるようにするとか

> - +#ifndef __LP64__ は本当にこれがやりたいんだろうか.あと -2 って何?

Linux + glibc限定だとmalloc headerがsize_t*2なのでこれで動くという決め打ちコードに見えてしまう・・・

In This Thread