peter green wrote:
> surely this also means
>
> 1: there has to be rtti for every field in every class so the compiler can
> follow the paths from the class
That's almost required, not only for classes but for all data types that
contain references (pointers) to managed objects.
It's not necess
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich
> Sent: 01 March 2005 07:33
> To: FPC developers' list
> Subject: Re: [fpc-devel] Improving Ref Counting
>
>
> Jamie McCracken wrote:
>
> > A GC nee
Jamie McCracken wrote:
> 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?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
Jamie McCracken wrote:
> 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?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
Jamie McCracken wrote:
> 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?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
>>> But it could be used on platforms that have a "fairly" stable and
>>> standardised C++ ABI (windows and Linux mainly). Other platforms can
>>> use the current FPC generic method as a fallback.
>>
>>
>> FPC could use that trick on (pretty much?) any platform. It doesn't have
>> to be compatible
On 28 feb 2005, at 13:14, Jamie McCracken wrote:
FPC could use that trick on (pretty much?) any platform. It doesn't
have to be compatible with the official C++ abi of that platform
(just like the current technique isn't either). It just isn't
implemented yet.
Yes thats right which is why I thin
Jonas Maebe wrote:
On 28 feb 2005, at 12:26, Jamie McCracken wrote:
FPC uses an platform independent method. The C++ ABI isn't used.
But it could be used on platforms that have a "fairly" stable and
standardised C++ ABI (windows and Linux mainly). Other platforms can
use the current FPC generic
On 28 feb 2005, at 12:26, Jamie McCracken wrote:
FPC uses an platform independent method. The C++ ABI isn't used.
But it could be used on platforms that have a "fairly" stable and
standardised C++ ABI (windows and Linux mainly). Other platforms can
use the current FPC generic method as a fallback
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 language
> 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
>> 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
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 m
Uberto Barbini wrote:
> > You already have them in Iunknown, ansistrings and variants. Its all a
> > question of making them faster cause they are dog slow atm.
>
> I wish them "NOT" managed, you cannot free a interface in Delphi.
You can finalize it, so that it releases all private resources. T
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
05-02-27 19.28, skrev Marco van de Voort 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 i
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 momen
> >>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 C++ ABI the overhead is almost zero.
Out of curi
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 C+
> > 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
> none at all during intense compu
> 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
none at all during intense computations.
GC hav
05-02-27 14.23, skrev Uberto Barbini följande:
>> Afaik the simplest GC's need to have exclusive access to the heap and
>> stack, so it cant be run in parallell with ordinary processing.
>
> What you mean with parallell? I imagine that it's protected into a critical
> section.
Thats a possibilit
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
___
At 12:35 27-2-2005, you wrote:
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).
I note that ref counting is very fast without all the implicit
try..finally stuf
[ 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 linke
> 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,
> Afaik the simplest GC's need to have exclusive access to the heap and
> stack, so it cant be run in parallell with ordinary processing.
What you mean with parallell? I imagine that it's protected into a critical
section.
Anyway I'm not a GC expert but there's tons of stuff on GC theories and al
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 any
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 t
> 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 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 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
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 i
> > 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
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.
Are
> > 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.
> > Also
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 any
Uberto Barbini wrote:
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 references it is still valid and delete if
ap
> 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 refer
> 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 references it is still valid and delete if
> appropriate).
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).
I note that ref counting is very fast without all the implicit
try..finally stuff so I was wondering if it was
41 matches
Mail list logo
