- Original Message -
From: [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Saturday, February 26, 2005 12:05 PM
Subject: Re: [fpc-devel] dynamic package support
On Sat, 26 Feb 2005, Florian Klaempfl wrote:
Hans-Jrg Vasold wrote:
for a long time
DrDiettrich wrote:
Jamie McCracken wrote:
GC is very inefficient with memory and current implementations tend to
cost a lot performance wise too.
I don't see how GC is inefficient with memory?
Reference counting and (mark/sweep) garbage collection have a different
runtime behaviour: Reference
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether anything that
Marco van de Voort wrote:
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether
Marco van de Voort wrote:
a valid/invalid reference without accessing memory that is invalid in the mean
time.
How does a GC do this? It would have the same problem?
A GC manages all memory, local variable allocation inclusive. IOW, the
way a GC does it, is not possible in a mixed environment.
I also thought immediately what Uberto already said: how do you recognize
a valid/invalid reference without accessing memory that is invalid in the
mean time.
How does a GC do this? It would have the same problem?
A GC dont' try to recognize a valid/invalid reference, it is invoked to
Uberto Barbini wrote:
I also thought immediately what Uberto already said: how do you recognize
a valid/invalid reference without accessing memory that is invalid in the
mean time.
How does a GC do this? It would have the same problem?
A GC dont' try to recognize a valid/invalid reference, it is
A GC needs to trace an object's references to see if anything still
points to it. How else can it decide whether an object is no longer in use?
Yes, this is right, but it hasn't to decide if reference are valid or invalid.
Moreover also the simpliest GC techniques (mark'n'swift) are quite slow
05-02-27 12.35, skrev Jamie McCracken följande:
Hi,
Rather than continuing the GC stuff which seems fruitless I thought it
might be better to improve what we have with ref counting (whilst taking
a leaf out of the GC book as well).
A more simplictic alternative could be to have objects
A more simplictic alternative could be to have objects (declared to be
managed) managed in the same way as ansistrings.
This is exactly what delphi do with interfaces, the result is an orrible mess,
and passing them as parameters a nightmare.
Refcounted objects are possible, python used them
05-02-27 13.47, skrev Uberto Barbini följande:
A GC needs to trace an object's references to see if anything still
points to it. How else can it decide whether an object is no longer in use?
Yes, this is right, but it hasn't to decide if reference are valid or invalid.
Moreover also the
[ Charset ISO-8859-1 unsupported, converting... ]
Marco van de Voort wrote:
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of
On Sunday 27 February 2005 15:29, Peter Vreman wrote:
Why are you looking at GC/Refcounting when the problem is the try..finally?
It is better to rewrite the try..finally code using the C++ ABI for
exception handling.
+1
and it'd be benefical to all applications.
Bye Uberto
I almost finished the porting of the core part of IO to fpc.
I am *very* interested in seeing this working :)
Nice to know! ;)
I added bugs for the (few) function I had to rewrite or modify passing
from Delphi to fpc.
Anyway I'm still in trouble with streams.
IO use descendants of
Hi all,
I tried to compile lazarus(cvs) with 1.9.9 and got this error:
lclproc.pas(832,8) Error: Illegal type conversion: Text to record
type
on this line:
if TextRec(Output).Mode=fmClosed then
Mode and fmClosed are integers. Can anyone help me with this? (1.9.8
works fine)
--
Met
Uberto Barbini wrote:
On Sunday 27 February 2005 15:29, Peter Vreman wrote:
Why are you looking at GC/Refcounting when the problem is the try..finally?
It is better to rewrite the try..finally code using the C++ ABI for
exception handling.
+1
and it'd be benefical to all applications.
Using the
05-02-27 19.16, skrev Uberto Barbini följande:
Thats a possibility, but then you do not win anything by running it in a
thread. It could as well be run when a memory allocation is done, and then
as a subroutine.
No, because the background thread get more time slices during idle moments and
peter green wrote:
one thing i have heared (i don't use garbage collected languages much so
i've never seen this myself) is that the GC gets some CPU time and starts
causing stuff to be swapped in. This slows other threads down which gives
the GC more CPU and causes more stuff to be swapped
Peter Vreman wrote:
Why are you looking at GC/Refcounting when the problem is the try..finally?
It is better to rewrite the try..finally code using the C++ ABI for
exception handling.
Where do you see improvements in the C++ ABI? Or even differences?
Windows implements this ABI, and every
Jamie McCracken wrote:
Rather than continuing the GC stuff which seems fruitless I thought it
might be better to improve what we have with ref counting (whilst taking
a leaf out of the GC book as well).
A reasonable attempt.
2) Have a single linked list that contains references to all
Why are you looking at GC/Refcounting when the problem is the
try..finally?
It is better to rewrite the try..finally code using the C++ ABI for
exception handling.
Where do you see improvements in the C++ ABI? Or even differences?
Windows implements this ABI, and every language should use
You can finalize it, so that it releases all private resources. That's
common practice in a GC environment. But then you are responsible when
the interfaced object is referenced from one of the still remaining
references, and it fails to act properly due to the missing resources.
I wish I
22 matches
Mail list logo
