Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > 1.8.2 - conituations memory leak fixed?

Reply
Thread Tools

1.8.2 - conituations memory leak fixed?

 
 
Wilkes
Guest
Posts: n/a
 
      01-19-2005
Is this still an issue with the "official" release?

- Wilkes

 
Reply With Quote
 
 
 
 
ts
Guest
Posts: n/a
 
      01-19-2005
>>>>> "W" == Wilkes <(E-Mail Removed)> 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






 
Reply With Quote
 
 
 
 
jc
Guest
Posts: n/a
 
      01-19-2005
This was posted recently:
http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/124213

 
Reply With Quote
 
ts
Guest
Posts: n/a
 
      01-19-2005
>>>>> "j" == jc <(E-Mail Removed)> writes:

j> This was posted recently:
j> http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/124213

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


Guy Decoux


 
Reply With Quote
 
Michael Neumann
Guest
Posts: n/a
 
      01-19-2005
Am Mittwoch 19 Januar 2005 16:53 schrieb ts:
> >>>>> "j" == jc <(E-Mail Removed)> writes:

>
> j> This was posted recently:
> j> http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/124213
>
> 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


 
Reply With Quote
 
Eric Hodel
Guest
Posts: n/a
 
      01-19-2005
--Apple-Mail-15--996546503
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


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

> Am Mittwoch 19 Januar 2005 16:53 schrieb ts:
>>>>>>> "j" == jc <(E-Mail Removed)> writes:

>>
>> j> This was posted recently:
>> j> http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/124213
>>
>> 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 - http://www.velocityreviews.com/forums/(E-Mail Removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-15--996546503
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB7qg4MypVHHlsnwQRAvVfAJ93kEziioJxwT5vwAOWk8 s46LfEEACfdOQl
4zrtG/9+ofsy35YCUhGKZ84=
=WEUc
-----END PGP SIGNATURE-----

--Apple-Mail-15--996546503--


 
Reply With Quote
 
Michael Neumann
Guest
Posts: n/a
 
      01-19-2005
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 <(E-Mail Removed)> writes:
> >>
> >> j> This was posted recently:
> >> j> http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/124213
> >>
> >> 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


 
Reply With Quote
 
Michael Neumann
Guest
Posts: n/a
 
      01-19-2005
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


 
Reply With Quote
 
jc
Guest
Posts: n/a
 
      01-19-2005
The last Ruby Weekly News has something that might be helpful here:

http://rubygarden.org/ruby?RubyNews/2005-01-03

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.

 
Reply With Quote
 
Eric Hodel
Guest
Posts: n/a
 
      01-20-2005
--Apple-Mail-33--976818807
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

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 <(E-Mail Removed)> writes:
>>>>
>>>> j> This was posted recently:
>>>> j>
>>>> http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/124213
>>>>
>>>> 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 - (E-Mail Removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-33--976818807
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB7vVIMypVHHlsnwQRAoO6AJwPG9SW27wpBmTLbxWUwi 9GwZze9QCgpYuF
EEFhp1l2al1e0SESepfRiWs=
=zqsC
-----END PGP SIGNATURE-----

--Apple-Mail-33--976818807--


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Memory leak even after deleting memory pointers from vector cham C++ 5 09-25-2008 10:30 AM
Leak or no leak ?? Richard Heathfield C Programming 4 07-10-2006 11:37 AM
Dynamic memory allocation and memory leak... s.subbarayan C Programming 10 03-22-2005 02:48 PM
Memory leak??? (top reporting high memory usage under Solaris) Mark Probert Ruby 4 02-09-2005 06:13 PM
Wireless Zero Configuration Memory Leak?? =?Utf-8?B?Umlja3NjaHVsdHox?= Wireless Networking 3 01-19-2005 11:26 PM



Advertisments