Path: news.cs.au.dk!not-for-mail
From: datpete@mjolner.dk
Newsgroups: comp.lang.beta
Subject: Re: Garbage Collector vs. cStruct, ExternalRecord, @@
Date: 16 Feb 1999 11:16:35 -0000
Organization: Mjolner Informatics ApS
Lines: 67
Approved: mailtonews@cs.au.dk
Distribution: world
Message-ID: <19990216111635.25715.qmail@noatun.mjolner.dk>
Reply-To: datpete@mjolner.dk
NNTP-Posting-Host: daimi.cs.au.dk
X-Trace: xinwen.cs.au.dk 919163810 6600 255.255.255.255 (16 Feb 1999 11:16:50 GMT)
X-Complaints-To: news@cs.au.dk
NNTP-Posting-Date: 16 Feb 1999 11:16:50 GMT
Xref: news.cs.au.dk comp.lang.beta:11824

Karl Waclawek writes:
> 
....
> The real slowdown IMHO is the fact that putByte performs an index check + a function call
> every time. For tasks like the ones in the code below one should have a "putBytes" pattern
> which takes a Char repetition as input or a control pattern "scanRange", so that one could
> do the following
> 
>   (1, 1000000) -> MyStruct.scanRange(# do Current -> MyGetValue -> Value #);
> 
> That way one would only have to perform the index checks for the boundaries
> and one could use a more efficient way to access a specific Byte position.
> 

This looks like a good idea!

....
> > The TestBuf is declared static in the Program SLOT. So as long as the
> > Program object exists (i.e. the lifetime of your program), the TestBuf
> > will exist.
> 
> Aha, so the compiler does not leave hints for the GC as to when some
> variables will not be in use anymore.

The problem here is the generality of patterns: You can have statis instances 
of patterns, in which you remote-access ("dot into") substance. Thus the static 
instances in a pattern should not just exist during the execution of the
do-part of the object (it may even not have a do-part), but during the whole
lifetime of the object containing the static instances.
> 
> > But as said, the use of @@ may easily cause access violations for other
> > reasons. And since GC almost never happens at exact the same spots in the
> > program, the behaviour may actually turn out to be non-deterministic.
> 
> I can understand that it is dangerous to mix GC and "manual" (de)allocation.
> I assume, that I can rely on a cStruct NOT being deallocated as long as it
> is in scope. If it goes out of scope then it may be GCed, even though some
> external code may still be using it. Is that correct?

This is correct, and this is a potential bug in the use of the C interface.
In general references to CStruct should only be handled to external functions
that behaves atomically in the sence that when the function returns to BETA,
the CStruct should no longer be referenced from the C code.
So either the C code should copy the CStruct or instead the pattern ExternalRecord
should be used. This implements CStruct access from BETA in externally allocated
memory. In this case, of course, deallocation is also manual.

> 
> P.S.: In a message posted Jan. 15 I mentioned a potential bug in %getByte
> (another undocumented pattern). Can you confirm that or was I doing
> something wrong in the sample code I posted?

I just posted a message with a confirmation of you observation. The bug is on
the intel based platform only, and have been corrected for the next release.

Sincerely,

Peter Andersen, Mjolner Informatics