[#407] New feature for Ruby? — Clemens.Hintze@...

Hi all,

27 messages 1999/07/01
[#413] Re: New feature for Ruby? — matz@... (Yukihiro Matsumoto) 1999/07/01

Hi Clemens,

[#416] Re: New feature for Ruby? — Clemens Hintze <c.hintze@...> 1999/07/01

On Thu, 01 Jul 1999, Yukihiro Matsumoto wrote:

[#418] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/01

Hi

[#426] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/02

Hi,

[#440] Now another totally different ;-) — Clemens Hintze <c.hintze@...>

Hi,

21 messages 1999/07/09
[#441] Re: Now another totally different ;-) — matz@... (Yukihiro Matsumoto) 1999/07/09

Hi,

[#442] Re: Now another totally different ;-) — Clemens Hintze <c.hintze@...> 1999/07/09

On Fri, 09 Jul 1999, you wrote:

[#443] — Michael Hohn <hohn@...>

Hello,

26 messages 1999/07/09
[#444] interactive ruby, debugger — gotoken@... (GOTO Kentaro) 1999/07/09

Hi Michael,

[ruby-talk:00500] Re: Ruby's GC (Re: Some questions concerning GC in Ruby extensions)

From: matz@... (Yukihiro Matsumoto)
Date: 1999-07-15 02:58:38 UTC
List: ruby-talk #500
Hi,

In message "[ruby-talk:00494] Re: Ruby's GC (Re:  Some questions concerning GC in Ruby extensions)"
    on 99/07/14, Clemens Hintze <c.hintze@gmx.net> writes:

|I have assumed, you use the Bohem's GC. Why not?

For several reasons:

  * When I linkded early Ruby with Bohem's GC 6 years ago, it dumped
    core.  I couldn't use it at leaset at that time.

  * Bohem's GC contains assmbler code, which means non portable.
    Ruby's GC is more portable, even though it's not fully portable.

  * Since Bohem's GC needs to treat arbitrary size of memory block,
    and from other resons, it is slower than Ruby's GC.

|Does the GC only
|collect data, which are some kind of Ruby object? What would happen
|with the memory allocated for `buf' in the following useless example?

As Shugo stated, it cause memory leak.

I think you are misunderstanding the words `true GC'.  It doesn't mean
'search & collect all unreferenced memory block', but means 'not a
cheaper substitution such as reference counting'.

Ruby's GC does not reclaim momory blocks not relating Ruby objects.

|   char *buf;
|
|   while (<some condition>) {
|      buf = ALLOC_N(char, 12);
|      strcpy(buf, "hello");
|      gc_start();
|   }
|
|Here the pointer `buf' will be overwritten many times. I have
|assumed, that there would not be any memory leak, as we have true GC.
|But now, after reading your explainations and after short studying of
|`gc.c', I fear, that it leaks the more memory, the more I repeat
|the loop!

You're right.  It leaks.

Ruby's GC frees you from memory trouble from Ruby objects and their
related memories.  But does not free you from ALL troubles.  You still
need to maintain usual memory usage as in normal C programs.

|Is here the memory pointed by `buf' safe? Or will I need a
|function like that: 
|
|   void mark_buf(strp)
|      struct string *strp;
|   {
|      rb_gc_mark(strp->buf);
|   }

You shouldn't mark strp->buf, because it's mere memory block, not a
Ruby object.  If a non object pointer is passed to the rb_gc_mark(),
it crashes.  If you designed your structures point to other Ruby
objects, you need to supply mark function.

|Will the memory pointed by `buf' be deleted during GC? Or have I to
|implement a `free_string' method like that:
|
|   void free_string(strp)
|      struct string *strp;
|   {
|      free(strp->buf);
|      strp->size = 0;     /* Okay! paranoid. */
|   }

Yes. And add free(strp) at the end.

|In the meantime... sorry for my bothering questions.

Not at all.
                                                matz.

In This Thread

Prev Next