Why does grabbing large recordset from the db uses somuch VM memory

[Mamapossible]

I'm using CF6.1, oracle db, jrun install (but the following is probably true
everywhere).

- In a controlled environement, I turn on metrics, start the server: free mem
is 99%. Normal
- I run a big query, say select * from table with 60000 records in there.
- 70 megs of ram are consumed by the VM.

I understand this. That's normal. What I don't understand, is WHY WON'T IT
GIVE IT BACK?

The page as finished executing. Why in the world is CF/jrun holding that
recorset in memory? WHy not immedialy free it? It's not longer referenced, no
longer used, no one is using the server, there is 0 activity. Yet it hold that
70meg recordset in ram for at least one minute before freeing it.

Garbage collection has nothing to do with it (I track GC and it has no effect
on that particular memory usage.)

Please, please, someone help. Even a pointer would be good enough. Anything :-D

MamaPossible.

[JaredJBlackburn]

The first thing to consider is whether or not you might be somehow caching the
query object that results from the cfquery call. The first way to do this is
to create the query object in a persistent scope. For instance, <cfquery
name="session.qname"... This is sometimes referred to as manual query caching
becasue the programmer is in control. The second way is to use the
cachedWithin and cachedAfter parameters in the cfquery tag. This is automatic
query caching because the server handles it. Settings for how many queries can
be chached at any giving time are in the CF Admin.

Assuming that you're not caching the query object, it's a matter of why the
Java Virtual Machine is taking such a long time to free the memory. It is the
nature on Garbage Collector to be mysterious. It is a low-priority thread that
runs when the JVM wants it to. It's not a system were memory is free as soon
as you're done with it. It's eligible to be free as soon as you're done. The
release happens when the garbage collector is given processor time by the JVM
and makes it to your no-longer-used memory. When there is still a lot of
unused memory available, the JVM will not run the garbage collector as much.
As memory becomes less plentiful, it will become a higher priority and the JVM
will grant it more processor time.

As a developer you have little or no control over it. However, in CF6&7 you
can instantiate java classes and run their functions. Using the <cfobject> tag
you can create an object from the Java System class and run the GC() function.
This doesn't NOT force the garbage collector to run, but rather encourages it.
Some developers like to call it after they know they have just finished with a
large piece of memory and it's now eligible for garbage collection - other
developers don't think it should ever be called but should be left alone to do
it's job.

Personally, I won't be too concerned about it. Remember the idea of garbage
collection is that developers don't have to worry about these kinds of things
so much.