I am looking for a real time garbage collector for Forth. If I cannot find one, I am considering building it, maybe using two Forth FPGA cores. One to run the application, the other to do the garbage collection. Maybe even doing it as a barrel
processor.

I am curious to hear your collective expertise on this matter.
Warm regards
Christopher Lozinski

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 8 June 2023 at 06:04:21 UTC+1, Christopher Lozinski wrote:

I am looking for a real time garbage collector for Forth. If I cannot find one, I am considering building it, maybe using two Forth FPGA cores. One to run the application, the other to do the garbage collection. Maybe even doing it as a barrel

processor.

I am curious to hear your collective expertise on this matter.
Warm regards
Christopher Lozinski

Can I point you to : http://www.complang.tuwien.ac.at/projects/forth.html
Anton has written a garbage collector. I have been meaning to use it but havent done so myself yet.

If you do decide to build it yourself, could you share which strategy
you chose to use eg mark & sweep or reference counting or something else.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

NN <november.nihal@gmail.com> writes:

On Thursday, 8 June 2023 at 06:04:21 UTC+1, Christopher Lozinski wrote:

I am looking for a real time garbage collector for Forth. If I cannot fin= >d one, I am considering building it, maybe using two Forth FPGA cores. One = >to run the application, the other to do the garbage collection. Maybe even = >doing it as a barrel processor.=20
=20
I am curious to hear your collective expertise on this matter.=20
Warm regards=20
Christopher Lozinski

Can I point you to : http://www.complang.tuwien.ac.at/projects/forth.html >Anton has written a garbage collector.

It's a stop-the-world garbage collector, not well-suited for real-time
use.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022 proceedings: http://www.euroforth.org/ef22/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you hugely for the information.
I am no expert on reference counting, but here are my basic ideas.
1. Read the literature. All the ideas have been published, I have access to the databases through my university library.
2. Probably do a reference counting garbage collection, including references on the stack. How do I know if a stack item is a reference or not? Well the lisp machine patents talk about extra bits on stack items. If the flag is set, it is a reference.
So then duplicating a reference on the stack increases the reference count. Dropping a stack reference decreases the reference count.
3. Many of the major garbage collectors use multiple approaches to catch circular references.
4. it could be a separate process. It would be interesting would be to let a second processor do the actual counting, and garbage collection, so that the first processor is not slowed down. The two processors will need to talk to each other. I am
most interested in many core forth processors.
4. Probably start with the MicroCore, and modify it to suit this application. Good to be part of a community, and base it on a mature product.

Of course Forth is mainly used in the real time community where the idea of garbage collection is considered dangerous. On the other hand, it would seem like this is something that every developer would like to have, if possible. It would be very nice
to be working on a project that someone was interested in using. It is okay to be doing something off of the main stream, but one should not be so far off that no one is interested.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/06/2023 20:42, Christopher Lozinski wrote:

Thank you hugely for the information.
I am no expert on reference counting, but here are my basic ideas.
1. Read the literature. All the ideas have been published, I have access to the databases through my university library.
2. Probably do a reference counting garbage collection, including references on the stack. How do I know if a stack item is a reference or not? Well the lisp machine patents talk about extra bits on stack items. If the flag is set, it is a

reference. So then duplicating a reference on the stack increases the reference count. Dropping a stack reference decreases the reference count.

3. Many of the major garbage collectors use multiple approaches to catch circular references.
4. it could be a separate process. It would be interesting would be to let a second processor do the actual counting, and garbage collection, so that the first processor is not slowed down. The two processors will need to talk to each other. I am

most interested in many core forth processors.

4. Probably start with the MicroCore, and modify it to suit this application. Good to be part of a community, and base it on a mature product.

Of course Forth is mainly used in the real time community where the idea of garbage collection is considered dangerous. On the other hand, it would seem like this is something that every developer would like to have, if possible. It would be very

nice to be working on a project that someone was interested in using. It is okay to be doing something off of the main stream, but one should not be so far off that no one is interested.

8th uses a reference-counting mechanism, but then it's not a real-time
Forth. RC does cost something, but in my usage scenarios it's not
particularly noticeable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 8, 2023 at 8:04:21 AM UTC+3, Christopher Lozinski wrote:

I am looking for a real time garbage collector for Forth. If I cannot find one, I am considering building it, maybe using two Forth FPGA cores. One to run the application, the other to do the garbage collection. Maybe even doing it as a barrel

processor.


Best is not to do any garbage collection in real time systems.
For example ENEA OSE RTOS uses strategy of having 8 configurable size buffers which are allocated
and then freed into 8 different pools.
During execution a certain number of different sized buffers will be allocated and freed, and that is then
the fragmentation of buffer sizes you will have in the system until it restarts.
Restart may happen for various reasons, including running out of buffer space.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <07c31729-91a9-45cf-899d-e7da83302462n@googlegroups.com>, Christopher Lozinski <calozinski@gmail.com> wrote:

I am looking for a real time garbage collector for Forth. If I cannot
find one, I am considering building it, maybe using two Forth FPGA
cores. One to run the application, the other to do the garbage
collection. Maybe even doing it as a barrel processor.

"real time" . That is a huge constraint. That means that you have
to specify additional requirements. In fact it means that the
garbage can only run x microseconds at a time, and consume no
more than x% of the total processor capacity.
Outside of the context of a real project that makes no sense.

OTOH if you are investigating garbage collectors that run piecemeal
versus those that stop the whole operation while its collecting.
That is legitimate, and running the collector non stop parallel
in another thread is interesting.

The most efficient "garbage collector" in real time system is
to pick up the garbage as you go, i.e. free storage as soon as
you're finished. That means you cannot operate at a high level
of abstraction. For real time that is not a good idea anyway.

I am curious to hear your collective expertise on this matter.
Warm regards
Christopher Lozinski

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)