does Access have a garbage collection feature? (1 Viewer)

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:54
Joined
Feb 28, 2001
Messages
27,001
Unfortunately, not a dynamic one. The "manual" method is called "Compact & Repair" and is how you clean up a database file that has become loaded with obsoleted records.

The problem stems from the fact that the database file is MAPPED into a 32-bit address space along with Access itself, all of the .DLL files, the Heap, the Stack, and whatever other internals have to be loaded up. The 32-bit address space is 4 GB, of which 2 GB is the dynamic part and all programs EXCEPT the VBA code, and the other 2 GB is the database file or files including the VBA code. Because Access MAPS that space as a virtual array, that makes it a SHARED virtual array (if it is a shared DB) and you cannot dynamically garbage collect the shared BE file because potentially, other people either ARE using it, or will shortly (and unpredictably) use it. GC would lead to destructive interference and a corrupt database file. That is why you need the stand-alone C&R process.

There is also no garbage-collection that attempts to clean the Heap (unless it is new after Ac2010). The stack gets re-used a lot like any stack would, so it does automatic GC simply by exiting from another layer of subroutines. But that is the nature of a stack.

Here, the GC problem is the same one that is shared by every operating system I have ever seen - eventually your dynamic RAM scratchpad gets too cluttered with old notes that cannot safely be merged and reclaimed without thrashing the memory management hardware. I once analyzed an OpenVMS app with a manually programmed style of scratchpad management where the virtual memory reclamation took 72 hours. But if you commented out the reclamation and merely marked the memory as "no longer in use" the program exited in 1 hour and returned ALL of its memory in a way that could be erased immediately. I.e. bulk GC rather than piecemeal GC.

There are strategies for O/S memory usage called "lookaside lists" and they help a lot, but the net result is that there IS no really good garbage collection scheme that doesn't usually take longer than it would to just reboot or exit and start from a fresh copy that is inherently defragged initially.

This quote from your referenced article is the operative one:

Like other memory management techniques, garbage collection may take a significant proportion of total processing time in a program and, as a result, can have significant influence on performance. With good implementations and with enough memory, depending on application, garbage collection can be faster than manual memory management, while the opposite can also be true
 

vba_php

Forum Troll
Local time
Today, 16:54
Joined
Oct 6, 2019
Messages
2,884
The "manual" method is called "Compact & Repair" and is how you clean up a database file that has become loaded with obsoleted records.
but doesn't it kill any memory that is still hanging around but not in use as well?
The problem stems from the fact that the database file is MAPPED into a 32-bit address space along with Access itself, all of the .DLL files, the Heap, the Stack, and whatever other internals have to be loaded up.
is this what you're talking about?



I'm assuming it is. I've only messed around with assembly language one time, and that was just out of curiosity. But I've done plenty with hexadecimal numbers, using them as readable substitutes for machine language. I did a lot of that junk at Collins Aerospace because the planes couldn't run on high level languages. All of the database entry and exit points like waypoints, approaches, and runways were communicated in binary language.
 

Attachments

  • windows_address_locale_32bit.png
    windows_address_locale_32bit.png
    20.4 KB · Views: 169

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:54
Joined
Feb 28, 2001
Messages
27,001
but doesn't it kill any memory that is still hanging around but not in use as well?

By the fact that you need exclusive rights on the DB being compacted, all RAM has already been released. None is hanging around. There is a moment before you start a C&R according to preferred methods such that the DB file is closed and has no component in memory. That is what I mean by "no RAM is hanging around."

In Windows, when you have a process with its own stack and heap management (and Access falls into that category), they can bollix up memory as they will. Windows doesn't care because it gave the process that memory precisely for its own use.

Once you talk about gaining exclusive access to the DB, you often have to close and re-open Access, selecting the option for exclusive access, in order to do this properly. OK, it is POSSIBLE to do this without closing first. However, normally you would close the file and open it in exclusive mode.

In so doing, your non-exclusive process runs through what is called "process rundown" which ends when Windows reclaims ALL memory (program, data, stack, heap, and miscellaneous loose stuff) that had been part of the process hosting the MSACCESS.EXE image. Anything that HAD been part of the Access infrastructure has been dissolved and wiped clean. (There are exceptions having to do with shared image sections but they don't invalidate the argument.) The reclaimed memory from a process run-down goes to the Free Page list because the Exit forces a write-back and flush of any pending "dirty" buffers before the rundown can complete.

As to the second part of your question: Yes, part of the problem is pointers. You can't release the memory because you cannot assure there are no pointers to it unless you do a full-blown C&R, which does what it does in the order that it names. The first thing is compaction. That is when unused (obsolete) items in the DB file are identified by "deleted" flags for each one. Access simply copies what ISN'T deleted into a new file. Then it closes the old file, deletes it, and renames the new file to match the name used by the old version.

The second thing is trickier - repair, which means that Access has to visit every internal structure to verify the pointers are consistent. Access is all about pointers. That is why even manual GC is such a pain and why it takes a while. It is only possible because the structures used in Access contain "markers" that help Access validate what it sees. What I know about this has been gleaned from a few articles over the years and I don't know if I still have the links. But the idea is that each memory structure has a fixed-structure header followed by a sub-structure dependent on what type of structure it represents. No, I don't have details on that. MS doesn't publish Access internals. (Darn it.)
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:54
Joined
Feb 28, 2001
Messages
27,001
I will continue to answer technical questions including yours, but I'm done playing the game that you have been playing. You already know how I feel about your "what God wants" question so I will ignore it.

You are welcome for the technical lesson.
 

vba_php

Forum Troll
Local time
Today, 16:54
Joined
Oct 6, 2019
Messages
2,884
but I'm done playing the game that you have been playing. You already know how I feel about your "what God wants" question so I will ignore it.
I wasn't playing any game, sir. Nor was I ever. regarding "wanting", I was referring to you coming out of your shell of believing that nothing happens after death and we just "wink out". That's not true, dude.
 

vba_php

Forum Troll
Local time
Today, 16:54
Joined
Oct 6, 2019
Messages
2,884
don't get mad Richard! I'm just trying to show you a little compassion and love, man! :) can't you see that?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:54
Joined
Feb 28, 2001
Messages
27,001
Your compassion in this case is misguided and therefore not well-received. You might as well offer hamburgers to starving vegan vegetarians. Your offer of help completely ignores the nature of the person to whom you offer it. Can't YOU see THAT?
 

vba_php

Forum Troll
Local time
Today, 16:54
Joined
Oct 6, 2019
Messages
2,884
Your compassion in this case is misguided and therefore not well-received. You might as well offer hamburgers to starving vegan vegetarians. Your offer of help completely ignores the nature of the person to whom you offer it. Can't YOU see THAT?
I can't help u anymore Richard. Sorry.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:54
Joined
Feb 28, 2001
Messages
27,001
Adam, we can work better together if you just don't TRY so damned hard to push me where you know I won't go. Acknowledge that simple fact and I can forgive your impetuousness and irreverence (even if I still somewhat disapprove.)
 

vba_php

Forum Troll
Local time
Today, 16:54
Joined
Oct 6, 2019
Messages
2,884
Adam, we can work better together if you just don't TRY so damned hard to push me where you know I won't go.
I understand, Doc. I never intended to push you, nor did any of my words do that to you. But this statement of yours, as I see it, is a very clear indication that you've encountered way too many "untrue" christians that are not compassionate and are skewed in their view and efforts of helping people explore the faith. So let us just go on with this software work of ours.
 

Users who are viewing this thread

Top Bottom