Re: the advantages of garbage collection

Walden H. Leverich wrote:

But in a managed environment you don't allocate "memory" you allocate
objects. If you needed 200K of memory for <insert you need here> you
wouldn't alloc it, you'd create a new byte[] object, or perhaps a
MemoryStream. Then these are objects, and the GC will know when they are
no longer referenced and can be cleaned up.

Yes. I don't understand your point.

RPG doesn't deal (directly) with objects, it deals with memory. If you allocate memory for a variable, it's your responsibility to deallocate it. If you don't allocate memory, then you have nothing to worry about.

Also, in RPG you don't create a new byte[] object, you would use a character array. Different concept. True, you could use the java interface in RPG ... but at that point you aren't operating in RPG anymore and it's the JVM's responsibility to do the GC.

The only spot the GC needs help is when you're transitioning to
non-managed code. If you allocate memory and then need to pass a pointer
to that memory to non-managed code, then you need to tell the GC to pin
the memory and leave it alone. The GC can tell when managed code is
using the memory, it can't tell when non-managed code is using it.
Therefore you must then un-pin the memory when it's no longer needed in
the called code.

I'm not sure how that applies to the discussion.

In Java, when you remove all references to an object, the garbage collector will clean it up when appropriate.

In RPG, it's the programmers responsibility to deallocate memory if it's is being dynamically allocated. The system doesn't know when the allocated memory is no longer used.

Also, in RPG, dynamic memory allocation is not a technique I would expect to be commonly used. It *CAN* be used, but I suspect the situations where it's necessary (at least in most RPG applications) are fairly rare. Probably mostly in cases where the application is a tool.

david