Re: the advantages of garbage collection

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Steve Richter wrote:
> the problem with this approach is what do you do if the driver CL
> module never ends? It's function is to process requests from a data
> queue. By never returning, the AG would not be reclaimed, and the job
> would eventually have gigabytes of memory allocated.
>   
I'm trying to avoid the GC part of this conversation; I spent way too 
many years dealing with memory leaks (no comments, eiteher <grin>).  You 
either do your own memory management (the C model), or you relegate it 
to the runtime (the Java model).  Technically, RPG follows the C model, 
but very few programmers ever need to allocate memory.  If you're 
writing code that requires a lot of memory allocation, you're either 
doing something you oughtn't to be doing, or you're as smart as Scott 
Klement and you will do the memory management correctly.

(Interestingly enough, if you look carefully at the Java interface for 
RPG, you'll see where the two models collide.  The interface has 
specific calls to perform GC for object references.  You can either do 
it an object at a time or you can set a reference frame and then clean 
up everything when you're done.  Quite elegant, actually.)

Allocating resources is a different animal, though.  We all allocate 
resources, whether it's open data paths or object locks or what have 
you.  With the proliferation of service programs and called programs 
that don't set on *INLR, it's normal.  But the statement above simply 
misses the point.

If you have a request processor and you want to process everything and 
you want to use AG as a cleanup, you have two recourses.  One is to use 
*NEW on the call from the request processor to the business logic.  This 
means that each request will automatically get cleaned up before the 
next request is processed.  Simple and easy to implement, but not quite 
as flexible.  The second is to have the business logic run in a named 
AG. With this, if two requests come in that are logically related, you 
can simply call the business logic and the state of the AG is 
essentially retained.  If, however, you need cleanup, then the request 
processor does a reclaim of the named AG. Again, very simple, but it 
does require a little more work on your part.

But in both cases, there should be one obvious point: the request 
processor is in a *different* AG than the actual business logic.  This 
is as it should be.  If you are actually doing distinct units of work 
that may require significant cleanup, then the AG boundary is exactly 
the way to segregate that workload, and the point of segregation is when 
you read a request and figure out what to do with it.

Joe