headers
Tatsuya BIZENN | 1 Jan 2006 07:37

Re: memory leak?

Maybe this patch fixes the problem.

http://article.gmane.org/gmane.comp.programming.garbage- 
collection.boehmgc/1066

On 2005/12/22, at 16:25, Shiro Kawai wrote:

> It runs in bounded memory on Linux/x86, but I do see a HUGE
> leak on MacOSX.  It seems that if I allocate something inside
> the loop, it isn't collected at all (forcing gc inside the loop
> make leak even harder).   Could be a GC problem specific to OSX,
> but I have no idea so far.
>
> --shiro
>
>
> From: KIMURA Shigenobu <skimu <at> mac.com>
> Subject: [Gauche-devel] memory leak?
> Date: Wed, 21 Dec 2005 23:57:50 -0600
>
>> Hello,
>>
>> If I do as follows and monitor the process by top command,
>> the memory usage of gosh is getting bigger and bigger.
>>
>> $ cat fo.scm
>> (let loop ()
>>    (format #t "abracadabra\n")
>>    (loop))
>> $ gosh fo.scm > /dev/null
(Continue reading)

Permalink | Reply | 1 comment |
headers
KIMURA Shigenobu | 1 Jan 2006 08:07
Picon

Re: memory leak?

Confirmed.

Now

(let loop ()
   (format #t "abracadabra\n")
   (loop))

stays in bounded memory on MacOS　10.4.3, that is,

$ uname -a
Darwin dragon.local 8.3.0 Darwin Kernel Version 8.3.0: Mon Oct  3  
20:04:04 PDT 2005; \
root:xnu-792.6.22.obj~2/RELEASE_PPC Power Macintosh powerpc

thanks.

-- skimu

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Permalink | Reply | 0 comments |
headers
Arto Bendiken | 5 Jan 2006 09:41
Picon
Gravatar

Problem redefining primitives

Hi guys,

I ran into a bit of trouble trying to redefine some of Gauche's
primitive bindings. The following works just fine:

(define %define% define)
(define-macro (define . args)
  `(%define% , <at> args))
(define xyz 123)
(print xyz)

However, when enclosing the first two forms in a 'begin' block, as
follows, Gauche 0.8.6 seems to go into an infinite loop:

(begin
  (define %define% define)
  (define-macro (define . args)
    `(%define% , <at> args)))
(define xyz 123)
(print xyz)

Is this a bug, or am I simply trying to press the envelope too much?

What I'm attempting to do is "hijack" the definitions of several of
Gauche's environment-modifying primitives, in order to inject into
them some diagnostic code that would be run whenever a 'define',
'define-method', 'define-macro' etc. is performed. (I need the 'begin'
wrapper as this code would go into a recursive macro and I'd get
errors about 'define-macro' needing to be a top-level form,
otherwise.)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Shiro Kawai | 6 Jan 2006 12:40
Favicon

Re: Problem redefining primitives

OK, this is a tricky stuff, but I do see its usefulness.
Let me explain what's happening, then suggest improvements.

First, keep these in mind:

(1) Gauche reads one toplevel form at at time, compiles it,
    then executes it.
(2) Macro definitions are evaluated at the compile stage.

Now, if 'begin' is used, Gauche takes the entire begin form
at once and compiles it.

(begin
  (define %define% define)
  (define-macro (define . args) `(%define , <at> args)))

The first form will be compiled into something like the
following sequence of commands:

  { lookup and get the value of global variable 'define' in the
    current module }
  { create a global variable '%define' and set the above value to it }

Note that, at this moment, those commands are not executed yet.

Then the compiler sees the second form.  It is a macro definition,
so the compiler evaluets it---that is, it compiles the macro
transformer and _bind_it_to_the_variable_define_ at this moment.

The compiler finishes compiling the begin form.  Now it executes
(Continue reading)

Permalink | Reply | 8 comments |
headers
Shiro Kawai | 7 Jan 2006 12:31
Favicon

Re: thread termination

Sorry for the belated response.
I need to check if using asynchronous cancellation causes
any problem.  Another way is to insert a cancellation point
in VM loop, but that could be too expensive.  Anyway,
thread-terminate! should be able to terminate a thread,
no matter what it is doing.

--shiro

From: Tomas Stanek <sad0ur <at> psi.cz>
Subject: [Gauche-devel] thread termination
Date: Mon, 14 Nov 2005 18:50:28 +0100

> Hello,
> 
> I've noticed that created threads use default cancelation type
> (PTHREAD_CANCEL_DEFERRED), so threaded code like:
> (let loop () (loop))
> is not terminable by thread-terminate!.
> 
> Adding:
> 
> pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
> 
> to thread_entry routine fixes the problem, but I'm not sure if there
> couldn't be some internal state inconsistency due to this (I haven't
> encountered any problems so far).
> 
> Tomas Stanek
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tomas Stanek | 7 Jan 2006 16:11
Picon
Favicon

Re: thread termination

On Sat 07.01 (01:31), Shiro Kawai wrote:
> Sorry for the belated response.
> I need to check if using asynchronous cancellation causes
> any problem.  Another way is to insert a cancellation point
> in VM loop, but that could be too expensive.  Anyway,
> thread-terminate! should be able to terminate a thread,
> no matter what it is doing.
> 
> --shiro

Hello

I thought the issue was abandoned/considered uniteresting, so I didn't
send more observations (Apology from my side as well...)

Simply adding the line I'we sent may lead to deadlock in gauche itself
(on ScmVM->vmlock), but that's not so bad. More problematic issue here
is the garbage collector. In example I'we sent, there is no problem,
since no allocation take place in that simple loop. But when
allocation/garbage collection does take place, GC locks its internal
mutex and termination can occur in GC's critical section, leaving the
mutex locked (maybe bug for boehm weiser GC). Thing are even more
complicated, because gauche allocates an exception in thread_cleanup
routine in case of external thread termination.

I've solved things just for my purposes, but not in general
(And unfortunately, I'we lost my version of gauche).

I currently have other priorities, but I could resurrect the issue if
desirable...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Shiro Kawai | 7 Jan 2006 22:23
Favicon

Re: thread termination

From: Tomas Stanek <sad0ur <at> psi.cz>
Subject: Re: [Gauche-devel] thread termination
Date: Sat, 7 Jan 2006 16:11:36 +0100

> On Sat 07.01 (01:31), Shiro Kawai wrote:
> > Sorry for the belated response.
> > I need to check if using asynchronous cancellation causes
> > any problem.  Another way is to insert a cancellation point
> > in VM loop, but that could be too expensive.  Anyway,
> > thread-terminate! should be able to terminate a thread,
> > no matter what it is doing.
> > 
> > --shiro
> 
> Hello
> 
> I thought the issue was abandoned/considered uniteresting, so I didn't
> send more observations (Apology from my side as well...)

Quite opposite, actually.  It seemed important but not
easy to tackle, so I put off until I have enough chunk
of time to work on it, and then somebody must have put me
in cold sleep for two months---hey, where's those men in gray?

Anyway, it needs to be addressed eventually, if not soon.
Asynchronous cancelling seems too dangerous.   I think I can
make VM loop occasionally call pthread_testcancel(), so that
the busy VM loop can be interrupted by deferred cancellation.
GC would be hard.  Maybe disabling cancellation while GC is
holding the global lock?
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Kilburg | 7 Jan 2006 23:46

Re: thread termination

>From: Tomas Stanek <sad0ur <at> psi.cz>
>Subject: Re: [Gauche-devel] thread termination
>Date: Sat, 7 Jan 2006 16:11:36 +0100
>
>> On Sat 07.01 (01:31), Shiro Kawai wrote:
>> > Sorry for the belated response.
>> > I need to check if using asynchronous cancellation causes
>> > any problem.  Another way is to insert a cancellation point
>> > in VM loop, but that could be too expensive.  Anyway,
>> > thread-terminate! should be able to terminate a thread,
>> > no matter what it is doing.
>> > 
>> > --shiro
>> 
>> Hello
>> 
>> I thought the issue was abandoned/considered uniteresting, so I didn't
>> send more observations (Apology from my side as well...)
>
>Quite opposite, actually.  It seemed important but not
>easy to tackle, so I put off until I have enough chunk
>of time to work on it, and then somebody must have put me
>in cold sleep for two months---hey, where's those men in gray?
>
>Anyway, it needs to be addressed eventually, if not soon.
>Asynchronous cancelling seems too dangerous.   I think I can
>make VM loop occasionally call pthread_testcancel(), so that
>the busy VM loop can be interrupted by deferred cancellation.
>GC would be hard.  Maybe disabling cancellation while GC is
>holding the global lock?
(Continue reading)

Permalink | Reply | 0 comments |
headers
todd ingalls | 10 Jan 2006 01:28
Picon
Favicon

Scm_AttachVM

Hi,
I am using .8.6.0 release on OSX 10.4.3. I have created a private  
framework per Install instructions also with pthreads enabled. I am  
having problems with I am trying to use Scm_AttachVM to attach a vm  
to a (GC_)pthread in an application in which i wish to embed gauche.  
Below is a very simple example.

What happens is that ScmAttachVM fails at this line:

  if (vm->thread != (pthread_t)NULL) return FALSE;

Is this correct behavior? Am I misunderstanding something fundamental  
about the Scm_AttachVM API. This seems odd to me. Any help would be  
greatly appreciated!

-------------

#include <stdio.h>
#include <Gauche/gauche.h>

void vm_thread(ScmVM *vm);

int main (int argc, const char * argv[]) {
	
	ScmVM *my_vm;
	pthread_t gauche_thread;

	my_vm = Scm_NewVM(NULL, SCM_MAKE_STR_IMMUTABLE("foo"));
		
	printf("pthread_create returned - %i\n", pthread_create
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arto Bendiken | 10 Jan 2006 17:56
Picon
Gravatar

Re: Problem redefining primitives

Hi Shiro,

Thanks to your very helpful reply, I've made some progress on this:

On 1/6/06, Shiro Kawai <shiro <at> lava.net> wrote:
> OK, this is a tricky stuff, but I do see its usefulness.
> ...
> (2) It is undefined in R5RS to take a value of syntactic keyword.
>     The current Gauche behavior is just a side effect of the
>     current implementation, and is not guaranteed to work in
>     future versions of Gauche.

When I started experimenting with this, I tried a couple of the other
popular Scheme interpreters, but they couldn't keep up. Side effect or
not, Gauche's current approach feels logical.

> You might also want to limit this aliasing effect within
> certain modules.  Some form equivalent to define-in-module,
> with which you can inject new definition into some other
> modules, could be handy.

Please find attached my simple "syntax hook" library that now allows
you to do exactly this. It can be used as follows:

(use gauche.hook.syntax)

(define-syntax-hook define
  (lambda (_ variable . expression)
    (format #t "DEBUG: (define ~a ~a)\n" variable expression)))
(Continue reading)

Permalink | Reply | 7 comments |

Gmane