Re: [MI400] Porting libgc to the AS/400

[Peter Colson <pcolson@xxxxxxxxxxxxxxx>]

On 19/10/2004, at 3:14 AM, Ted Slate wrote:

> If you plan to use it as part of a C program then maybe but you'll 
> probably have to use all IBM ILE-C. It's pretty much a closed book on 
> the /400(internals and ILE-C). I assume you mean a resident C program 
> running as a user job on the /400 and not a PC/C program accessing the 
> /400.

Yes, I'm using ILE-C program running on the 400 using teraspace options 
to present 8 byte pointers that can be bit manipulated 
(pointer-integral-pointer) without invalidating them (unlike native 16 
byte pointers).

> > From what I can gather on the libgc page, it tries to do a better job 
> > of
> re-allocating memory then malloc.  There are way too many hurdles and 
> most of the MI knowledge is generally about structures, use of the 
> documented MI language and some processes.  But creating another 
> malloc that re-allocates memory on the /400 is better left to IBM. 
> That's unfortunate but there's just no reliable published 
> documentation that would help you.  A great exercise but if your 
> serious would end in frustration.  The internals knowledge required is 
> too great.  You can already dynamically re-allocate memory in MI as 
> well as C, so I'm not sure what benefit the another gc is other than 
> maybe a better algorithm but it might not necessarily perform better 
> on the /400.
>
> For example, you would have to have internals knowledge of the ILE-C 
> or C heap storage and re-allocation algorithms, storage structures, 
> etc. to even begin determining if it's worth it. You'd have to hack 
> every bit of that information. Easily a full-time 1-3 month effort 
> solo.  But that's just my opinion, you may find it worth the effort, 
> but it would be all for your benefit, since no one in the /400 world 
> would use/trust it anyway.  Sorry!

Hmmm...not sounding good. It's not something I'm choosing to do, but 
the garbage collector is used by a larger app that requires it (and the 
ability to invoke a finalisation routine associated with memory 
(actually, objects) as they're garbage collected). The app in question 
is currently running natively on the 400 minus garbage collection.

Basically, the garbage collector has to manage memory usage on behalf 
of the app which provides an environment in which other programs can 
run.


Regards,
Peter Colson.