对了 when ... : ... 在 1.9 由于和 Hash 新语法冲突已经 deprecated 了。
要把冒号改成分号 ……

if RUBY_VERSION < '1.9'
  class String
    def each_char; self.each_byte {|b| yield b.chr }; end
  end
end
  
bfsrc = ARGF.read
arr = [ 'cell, ptr = [], 0' ]
bfsrc.each_char do |c|
  case c
  when /[+-]/ ; arr << "cell[ptr] ||= 0; cell[ptr] #{c}= 1"
  when '>' ; arr << 'ptr += 1'
  when '<' ; arr << 'ptr -= 1'
  when '[' ; arr << 'while 0 != cell[ptr]'
  when ']' ; arr << 'end'
  when '.' ; arr << 'print (cell[ptr] || 0).chr'
  when ',' ; arr << 'cell[ptr] = STDIN.getc'
  end
end
rbsrc = arr.join "\n"
eval rbsrc

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

$ ruby brainfck.rb hello.bf
Hello World!

。。好牛
http://www.acfun.cn/html/art/20090925/49306.html

Date: Mon, 28 Sep 2009 12:18:26 +0100
From: Dick Porter <dporter@codicesoftware.com>
Subject: [Mono-dev] RFC: GC precise scanning of stacks
To: mono-devel-list@lists.ximian.com
Message-ID:
<1254136706.18582.126.camel@hagbard.apathetic.discordia.org.uk>
Content-Type: text/plain; charset="us-ascii"

Hi all

We think some of our 'leak' issues can be attributed to libgc's
false-positive identification of pointers.

Attached is a proof-of-concept patch to libgc (and a simple
demonstration program) that I hope will be the start of GC precise stack
scanning.  The code should apply easily to sgen as well.

It basically adds an extra variable to the stack which contains specific
markers and references to all the pointers that will contain GC-alloced
memory.  There is an optional failsafe mode that will fall back to the
current 'all stack is scanned' code if the markers are not seen.

This code will cover objects on unmanaged stacks but I don't know what
will be needed for managed code.  I presume the JIT can add the same
sort of marker to the stack?

So, comments?  Is this technique going to be workable?

- Dick

Date: Mon, 28 Sep 2009 17:41:33 -0400
From: Miguel de Icaza <miguel@novell.com>
Subject: Re: [Mono-dev] Issues with GC due to libgc
To: "pablosantosluac@terra.es" <pablosantosluac@terra.es>
Cc: David Su?rez <dsuarezv@codicesoftware.com>, Dick Porter
<dporter@codicesoftware.com>, mono-devel-list@lists.ximian.com
Message-ID: <1254174093.5057.139.camel@erandi.site>
Content-Type: text/plain

Hello,

> Libgc supports this kind of descriptors and mono already generates
> them
> for the sgen gc, so it's just a matter of joining those together
> (which
> should beeasy to do). This should improve a great number of scans in
> the
> arking process, leaving only stacks and several minor objects without
> precise marking. (Should become similar to the current sgen idea,
> where
> stacks and other roots are scanned conservatively, although not
> compacting).

Mono already uses those descriptors for the heap;   There are only two
cases when it does not use that:

* Scanning the stack, this is done with the conservative
  collector.

* Any AppDomains that are not the root appdomain.   

The problem with scanning the stack precisely is that it requires the
JIT and the GC to work as a team to be able to at any point of the
execution to determine which values on the stack are pointers and which
values are not.    This is not trivial.

The problem with AppDomains is that upon unloading there is a potential
for leaking vtables, something that I do not particular think is as
important as being able to scan the AppDomains precisely.   We should
bring Ben's patch into Mono and just default to this.

There are ways of minimizing the problems that you are experiencing
today, some techniques might work better than others, but:

* Do not allocate large blocks of data, as they tend to fragment
  your heap;   Instead use smaller allocations, or use unmanaged
  buffers if you need to.

  This technique is used in Mono's ASP.NET precisely for that
  reason.

  See System.Web/HttpResponseStream.cs

* Make your stacks shallower.

Miguel.

Date: Tue, 29 Sep 2009 19:09:03 -0400
From: Miguel de Icaza <miguel@novell.com>
Subject: Re: [Mono-dev] Issues with GC due to libgc
To: Mark Probst <mark.probst@gmail.com>
Cc: David Su?rez <dsuarezv@codicesoftware.com>, Dick Porter
<dporter@codicesoftware.com>, mono-devel-list@lists.ximian.com
Message-ID: <1254265743.13957.34.camel@erandi.site>
Content-Type: text/plain

Hello,

> > I am not sure I understand from the description above how would leaking
> > the vtables kill SGen.
>
> The problem is not leaking VTables, but "leaking" objects across
> domains, i.e. having references from objects in one domain to objects
> in another domain.  Once that domain is gone, so are the VTables, so
> SGen cannot follow those references anymore, so it crashes.
>
> The fix for this is not to keep the VTables alive - it's to not make
> cross-domain references in the first place.

You just opened my eyes, thanks for the explanation.

Could you confirm that in this case:

AppDomain A: call Foo (obj a, obj c)
AppDomain B: enter Foo
AppDomain B: Unload A

That the objects "a" and "c" from AppDomain a would not live in the
stack?

Miguel.

Message: 1
Date: Sat, 17 Oct 2009 11:59:20 -0300
From: Rodrigo Kumpera <kumpera@gmail.com>
Subject: Re: [Mono-dev] RFC: GC precise scanning of stacks
To: Dick Porter <dporter@codicesoftware.com>
Cc: mono-devel-list@lists.ximian.com
Message-ID:
<8cca42d80910170759m2750bd25mdada426004758cad@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hey Dick,

Your patch won't work because it doesn't deal neither with on stack
temporaries or spilled variables
and can make the runtime somewhat slower since it marks as volatile all
locals holding managed objects.

It would not work for the top frame due to how threads are stopped by boehm
or sgen. Both collectors
park threads at random points[1] without any sort of safe-point mechanism.

There are a few ways to implement precise stack scanning for unmanaged code,
none are pretty thou:

-Make the whole runtime use gchandles to manipulate managed objects. Safe
parking is possible to be done
in a quite non-intrusive way. Coding using such thing is a major PITA as all
access have to be done using accessor
functions. The main issue with this approach is the __huge__ effort to fix
all code playing with managed objects.

-Only scan unmanaged frames from the runtime or DSOs that have registered
icalls. This is a pretty decent
compromise and should lead to a lot less false positives.

For managed code, we need to extend the JIT to either produce stack maps
that tell at each safepoint[2] which
stack slots are used for managed pointer and which are unknown (callee saved
regs, for example); or we can just
make sure stack slot for managed pointers are not reused for scalars, have a
single description of the stack and live
with some false positives due to uninitialized variables.

We could use a shadow stack for the JITd code, which is quite simples to
implement, but it has the issue of causing
slower code to be generated.


[1] SGen requires parking outside of allocators but otherwise it can be at
arbitrary points.
[2] Safepoints can pretty much be just at method call points since the top
frame will most likely be conservatively scanned.



On Mon, Sep 28, 2009 at 10:28 AM, Dick Porter <dporter@codicesoftware.com>wrote:

> Hi all
>
> We think some of our 'leak' issues can be attributed to libgc's
> false-positive identification of pointers.
>
> Attached is a proof-of-concept patch to libgc (and a simple
> demonstration program) that I hope will be the start of GC precise stack
> scanning.  The code should apply easily to sgen as well.
>
> It basically adds an extra variable to the stack which contains specific
> markers and references to all the pointers that will contain GC-alloced
> memory.  There is an optional failsafe mode that will fall back to the
> current 'all stack is scanned' code if the markers are not seen.
>
> This code will cover objects on unmanaged stacks but I don't know what
> will be needed for managed code.  I presume the JIT can add the same
> sort of marker to the stack?
>
> So, comments?  Is this technique going to be workable?
>
> - Dick

Date: Fri, 6 Nov 2009 12:42:41 +0100
From: Mark Probst <mark.probst@gmail.com>
Subject: [Mono-dev] SGen ready for early testing
To: mono-devel <mono-devel-list@lists.ximian.com>
Message-ID:
<f54ff3e80911060342gc6ff1a9oa03b6ea0da492659@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello everybody,

Our new garbage collector, SGen, is now at the point where it's ready
for early testing.  It's still a long way from being ready for
production use - it's still slow and consumes too much memory,
especially for long-running processes - but if you'd like to help us
find bugs, please consider giving it a try.  I'm especially interested
in cases where Mono crashes or hangs with SGen (other than for memory
exhaustion).  The simpler the test cases the better.

To use SGen instead of Boehm, configure mono with the switch
"--with-gc=sgen".  At this point it's only known to run on x86 and
AMD64 Linux.

Thanks!

Mark

Date: Fri, 6 Nov 2009 15:12:34 +0100
From: Mark Probst <mark.probst@gmail.com>
Subject: Re: [Mono-dev] SGen ready for early testing
To: Sharique uddin Ahmed Farooqui <safknw@gmail.com>
Cc: mono-devel <mono-devel-list@lists.ximian.com>
Message-ID:
<f54ff3e80911060612m64ceb09cl2ddff86489ef1cd1@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 6, 2009 at 2:18 PM, Sharique uddin Ahmed Farooqui
<safknw@gmail.com> wrote:
> Is this going to be included in 2.6 (as option along with Boehm) or it
> will be in next release?

SGen will be in 2.8 as an option.

Mark

http://www.cnbeta.com/articles/94553.htm
“联系了打个大西瓜的作者”