Asp Forum - 1.8.2 - conituations memory leak fixed?

Wilkes

1/19/2005 1:57:00 AM

Is this still an issue with the "official" release?

- Wilkes

14 Answers

ts

1/19/2005 5:11:00 AM

>>>>> "W" == Wilkes <wilkesjoiner@gmail.com> writes:

W> Is this still an issue with the "official" release?

Nobody has given, yet, the proof that it exist a memory leak with
continuations.

Guy Decoux

jc

1/19/2005 3:20:00 PM

This was posted recently:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-t...

ts

1/19/2005 3:53:00 PM

>>>>> "j" == jc <james.cromwell@gmail.com> writes:

j> This was posted recently:
j> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-t...

This is the proof that the GC is conservative, this does not mean that it
exist a memory leak.

Guy Decoux

Michael Neumann

1/19/2005 4:16:00 PM

Am Mittwoch 19 Januar 2005 16:53 schrieb ts:
> >>>>> "j" == jc <james.cromwell@gmail.com> writes:
>
> j> This was posted recently:
> j> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-t...
>
> This is the proof that the GC is conservative, this does not mean that it
> exist a memory leak.

Sure, but the results might be the same ;-)

Regards,

Michael

Eric Hodel

1/19/2005 6:35:00 PM

On 19 Jan 2005, at 08:15, Michael Neumann wrote:

> Am Mittwoch 19 Januar 2005 16:53 schrieb ts:
>>>>>>> "j" == jc <james.cromwell@gmail.com> writes:
>>
>> j> This was posted recently:
>> j> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-t...
>>
>> This is the proof that the GC is conservative, this does not mean
>> that it
>> exist a memory leak.
>
> Sure, but the results might be the same ;-)

I don't see a callcc in there anywhere, so
callback_stream.with_callbacks_for could be doing other naughty things.
From personal experience with callcc, I would bet on something
referencing live objects over any memory leaks.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Michael Neumann

1/19/2005 7:37:00 PM

Am Mittwoch 19 Januar 2005 19:35 schrieb Eric Hodel:
> On 19 Jan 2005, at 08:15, Michael Neumann wrote:
> > Am Mittwoch 19 Januar 2005 16:53 schrieb ts:
> >>>>>>> "j" == jc <james.cromwell@gmail.com> writes:
> >>
> >> j> This was posted recently:
> >> j> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-t...
> >>
> >> This is the proof that the GC is conservative, this does not mean
> >> that it
> >> exist a memory leak.
> >
> > Sure, but the results might be the same ;-)
>
> I don't see a callcc in there anywhere, so
> callback_stream.with_callbacks_for could be doing other naughty things.

Right. But it's the place where the callbacks are invoked. And the callback
that gets invoked actually uses callcc. It was very strange that, when I
change that line in some manner (introduce an assignment), the memory
consumption changes drastically.

> From personal experience with callcc, I would bet on something
> referencing live objects over any memory leaks.

I think the problem is due to the conservative GC. But of course, there might
also be some bugs in it (but then, memory consumption should be unbounded as
well, if I remove continuations, which I've done).

Regards,

Michael

Its Me

1/19/2005 7:39:00 PM

If it is something other than a memory leak, and if it is locatable :-)
would continuations in Wee become a 'recommended usage'?

"Eric Hodel" <drbrain@segment7.net> wrote

On 19 Jan 2005, at 08:15, Michael Neumann wrote:

> Am Mittwoch 19 Januar 2005 16:53 schrieb ts:
>>>>>>> "j" == jc <james.cromwell@gmail.com> writes:
>>
>> j> This was posted recently:
>> j> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-t...
>>
>> This is the proof that the GC is conservative, this does not mean
>> that it
>> exist a memory leak.
>
> Sure, but the results might be the same ;-)

I don't see a callcc in there anywhere, so
callback_stream.with_callbacks_for could be doing other naughty things.
From personal experience with callcc, I would bet on something
referencing live objects over any memory leaks.

Michael Neumann

1/19/2005 7:52:00 PM

Am Mittwoch 19 Januar 2005 20:41 schrieb itsme213:
> If it is something other than a memory leak, and if it is locatable :-)
> would continuations in Wee become a 'recommended usage'?

Hm, there's still another issue. You can't marshal continuations in Ruby.
Don't know whether they'd become recommended ;-)

But it's so easy to leave them out or integrate them back into Wee, so I don't
think about that issue yet.

Regards,

Michael

jc

1/19/2005 10:26:00 PM

The last Ruby Weekly News has something that might be helpful here:

http://rubygarden.org/ruby?RubyNews/...

Tanaka Akira posted a patch to record GC-related information:

* the total number of GC invocation
* the number of GC invocation, when an object is collected
* the location where the last GC is yielded
This patch might help you if you are interested in GC internals.

Eric Hodel

1/20/2005 12:05:00 AM

On 19 Jan 2005, at 11:36, Michael Neumann wrote:

> Am Mittwoch 19 Januar 2005 19:35 schrieb Eric Hodel:
>> On 19 Jan 2005, at 08:15, Michael Neumann wrote:
>>> Am Mittwoch 19 Januar 2005 16:53 schrieb ts:
>>>>>>>>> "j" == jc <james.cromwell@gmail.com> writes:
>>>>
>>>> j> This was posted recently:
>>>> j>
>>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-t...
>>>>
>>>> This is the proof that the GC is conservative, this does not mean
>>>> that it
>>>> exist a memory leak.
>>>
>>> Sure, but the results might be the same ;-)
>>
>> I don't see a callcc in there anywhere, so
>> callback_stream.with_callbacks_for could be doing other naughty
>> things.
>
> Right. But it's the place where the callbacks are invoked. And the
> callback
> that gets invoked actually uses callcc. It was very strange that, when
> I
> change that line in some manner (introduce an assignment), the memory
> consumption changes drastically.

Due to the way Ruby saves the environment, the problem could be on the
line you show, or it could be where callcc is invoked. Without a
simple testcase, its difficult to track this problem down to a memory
leak, or a result of the conservative GC/environment feature:

def x
w = :stuff
proc do # w is free in this proc, so we don't need to save any
reference to it
# in the proc
puts "w: #{eval "w"}" # grab w out of the environment
end
end

x.call # prints w: stuff
# Because ruby keeps the entire local variable table around, we
can get to w
--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

comp.lang.ruby

1.8.2 - conituations memory leak fixed?

Wilkes

ts

jc

ts

Michael Neumann

Eric Hodel

Michael Neumann

Its Me

Michael Neumann

jc

Eric Hodel

x Login to ForumsZone