[Oberon] FPGA - Garbage Collector - GC
Tomas Kral
thomas.kral at email.cz
Wed Apr 19 12:03:44 CEST 2017
Hi Christopher,
I see it in the code.
`Oberon.Mod', problem here with my FPGA is when `System.Mod'
recompiled, GC stops, even when `System.Collect' is executed manually.
MODULE Oberon; (*JG 6.9.90 / 23.9.93 / 13.8.94 / NW 14.4.2013 /
22.12.2015*)
...
VAR ActCnt: INTEGER; (*action count for GC*)
...
PROCEDURE GC;
VAR mod: Modules.Module;
BEGIN
IF (ActCnt <= 0) OR (Kernel.allocated >= Kernel.heapLim -
Kernel.heapOrg - 10000H) THEN mod := Modules.root; LED(21H);
WHILE mod # NIL DO
IF mod.name[0] # 0X THEN Kernel.Mark(mod.ptr) END ;
mod := mod.next
END ;
LED(23H);
Files.RestoreList; LED(27H);
Kernel.Scan; LED(20H);
ActCnt := BasicCycle
END
END GC;
...
BEGIN
ActCnt := 0; CurTask := NewTask(GC, 1000); Install(CurTask);
END Oberon.
1000 is polled interval in miliseconds?
Tomas
On Tue, 18 Apr 2017 18:25:33 +0930
Chris Burrows <chris at cfbsoftware.com> wrote:
> Hi Tomas,
>
> The Garbage Collector task is called every second. However it won't
> do anything (including flash the LED) unless 20 actions have been
> performed or the used memory exceeds a certain threshold. This is
> controlled in the procedure Oberon.GC.
>
> In an early version of Project Oberon that I had, the LED used to
> blink every second indicating that the GC was trying to do something
> even when it had nothing to do. I believe that this was fixed some
> time ago. Maybe that is what you are thinking of?
>
> Regards,
> Chris Burrows
>
> CFB Software
> http://www.astrobe.com/RISC5
>
>
> > -----Original Message-----
> > From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> > Tomas Kral
> > Sent: Tuesday, 18 April 2017 1:46 AM
> > To: oberon at lists.inf.ethz.ch
> > Cc: Andreas Pirklbauer
> > Subject: Re: [Oberon] FPGA - Garbage Collector - GC
> >
> > Hi Andreas, Paul,
> >
> > I only rebuilt the `FileDir.Mod' to obtain a symbol file needed as
> > import to `System.Mod'.
> >
> > I had backed the `System.rsc' to .Bak and deleted FileDir.{smb.rsc}
> > afterwards.
> >
> > It breaks GC all the same.
> >
> > This is diff on `System.Mod'
> >
> > pi at raspberrypi /usr/src/oberon/PO.V5.1 $ diff System.Mod.txt
> > ../PO.V5.0/System.Mod.txt
> > 1c1
> > < MODULE System; (*JG 3.10.90 / NW 12.10.93 / NW 20.6.2016*)
> > ---
> > > MODULE System; (*JG 3.10.90 / NW 12.10.93 / NW 28.11.2015*)
> > 89c89
> > < PROCEDURE Clear*; (*clear Log*)
> > ---
> > > PROCEDURE Clear*; (*used to clear Log*)
> > 93c93
> > < NEW(buf); Texts.OpenBuf(buf); T :=
> > F.next(TextFrames.Frame).text; Texts.Delete(T, 0, T.len, buf)
> > ---
> > > T := F.next(TextFrames.Frame).text; Texts.Delete(T, 0,
> > > T.len, buf)
> >
> > FileDir.Mod does not seem to have changed
> >
> >
> > pi at raspberrypi /usr/src/oberon/PO.V5.1 $ grep MODULE
> > > FileDir.Mod.txt
> > MODULE FileDir; (*NW 12.1.86 / 23.8.90 / 15.8.2013*)
> >
> > Tomas
> >
> >
> > On Fri, 14 Apr 2017 10:21:45 +0000
> > Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
> >
> > > If you have changed module FileDir, its variable size and/or its
> > code
> > > size will very likely have changed (even if the module interface
> > > itself has not changed). Therefore, pointers from within the
> > > module descriptor of FileDir, such as mod.code and mod.ptr, will
> > > no longer point to "correct" starting addresses in the various
> > > sections
> > inside
> > > the module block of FileDir.
> > >
> > > So you will likely have to rebuild the inner core and load it onto
> > the
> > > disk's boot area, e.g., by executing the commands [1]
> > >
> > > ORP.Compile Kernel.Mod FileDir.Mod Files.Mod Modules.Mod ~
> > > Linker.Link Modules ~ Builder.Build Modules ~
> > >
> > > Note: It is the linking process that will update the module area
> > > layout (i.e. the linked list of the four modules Kernel, FileDir,
> > > Files and Modules), such that *after* rebooting, pointers like
> > mod.ptr
> > > will be correct again. With the updated mod.ptr, the GC should
> > work.
> > > Please make sure to also recompile the rest of the Oberon system
> > > including the compiler itself *before* rebooting system
> > > - just in case module keys of the inner core modules have changed.
> > > Otherwise it may not come up again.
> > >
> > > Andreas
> > >
> > > [1] e.g. see
> > > http://github.com/andreaspirklbauer/Oberon-building-tools
> > >
> > >
> > >
> > > ------------------------------------------
> > > Tomas Kral thomas.kral at email.cz Fri Apr 14 10:49:39 CEST
> > > 2017Hi,
> > >
> > > Now I have figured out, recompiling OR.Compile FileDir.Mod
> > System.Mod
> > > ~ with most recent changes, stopped GC to collect garbage. Any
> > ideas
> > > what I may have done wrong? Do I have to rebuild inner core?Tomas
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
More information about the Oberon
mailing list