LINUX

[hwsw famulus]

>> Hatranynak  a GC miatti nagy overhead-t.
>
> PC-re csinaltam Java alapu hang- es kepfolyam feldolgozo rendszert. (Java 
> kellett, mert a kollegak ezt talaltak ki - az algoritmusok jo resze C-ben 
> irodott) En is feltem a GC-tol, ezert a nagyobb objektumokat 
> ujrafelhasznaltam, es 10 masodpercenkent meghivtam kezzel a szemetgyujtot. 
> Szerintem ezzel (es a felhasznalt eszkoz beepitett pufferelesevel) meg 
> lehet uszni az alkalmankenti leterhelest. Igaz, elesben nem nagyon lett 
> kiprobalva tobbfele okbol.
>
>  szia: Balazs

....ha, jol ertem van olyan GC megoldas ami nem allitja meg a main-t.

KJ

Garbage Collector Interface

Different types of (incremental) GC algorithms need different code 
constructs.

For example, to guarantee predictability, a mark-compact GC

requires all object references to include a read-barrier, while a 
readbarrier

would only be unnecessary overhead with a mark-sweep GC.

These differences makes it error-prone and troublesome to write code

generators supporting more than just one type of GC algorithm, and it

gets even worse considering hand-written code that needs a complete

rewrite for each supported GC type.

The GCI [IBE+02] is being developed within our group to overcome

these problems. The GCI is implemented as a set of C preprocessor

macros in four layers, as seen in figure 4.1, from the user layer via

threading and debug layers to the implementation layer.

The two middle layers can be switched on/off to support GCI debugging and/or

multi-threaded applications.



The test application was compiled and linked against two different GC

implementations;

one Mark-Sweep GC,

and one Mark-Compact GC. All

threads allocate garbage in their run loops, forcing the GC thread to

clean up the heap during idle time.



Results from the experiments are shown in Figures 6.2 and 6.3, and

some statistics are found in Table 6.5. From these results, we can draw

a number of conclusions regarding the real-time behavior:

. Latency and response times are quite good. The amount of jitter is

well within margins for thread T1, bearing in mind that we have a

sampling frequency of 10 kHz and a system with more than 90%

CPU load.

. There is a slight, but notable, difference in performance between

the two GC algorithms used in the experiment. The reason for

the Mark-Sweep GC giving a slightly better performance is here

due to that GC synchronization can be made more efficient. The

performance differences between the two GC algorithms will be

further discussed in Section 6.3.2 below.