Re: Memory question
Martin Gregorie wrote:
Wrong term - I should have said sparse. If a lot of large objects have
become unreferenced as they go out of scope the heap is sparse for
active objects.
Which doesn't necessarily affect much. Active objects are referred to
directly so their contiguity has little to do with memory access speed. Even
if objects are next to each other in memory, there is no guarantee that the
program will use them in near time periods. Even if they are far apart in
memory is no guarantee that the program will need them at the same time and
run into swap trouble. In fact, the most likely scenario is that active
objects will live and die more or less at the same time, so the sparseness
about which you're concerned is unlikely to be much of a factor at all.
Of course, all of this is speculation without actual meory profiling, and
different applications will behave differently. Still, there is little reason
to expect "sparseness" to have much effect or even to be much present.
Lew wrote:
The page from which objects are copied is active for a
while, and the page to which the objects are copied is also active for
a while.
Martin Gregorie wrote:
True, but once the GC has finished its work paging should be reduced
somewhat simply because on average each page turn will now tend to fetch
more active objects. If active objects now occupy a much smaller part of
the heap space its possible that each will be paged into real memory as
a side-effect of GC operation and not paged out again for some time.
Yes, I see that.
It's just that if you're in a situation where memory is swapping like mad, you
probably have a whole lot of things using memory, and most of them likely
outside the instance of the JVM, so the swap situation is likely to remain bad
after GC cycles, too.
Even before the GC runs, pages that haven't been used but are not
collectible can become inactive, they will swap out and not swap in
again until needed.
Thats clear, but performance could be hurt if this unallocated heap
space is retained in the process' virtual memory space but is paged out
into swap space. It will have to be read in again before a new object is
allocated to it. Whereas, if the paged out virtual memory is released by
the GC then new objects can be allocated to newly claimed pages without
needing to touch disk unless/until they are paged out.
Trivially true, but probably not much help when your physical RAM is maxed.
At that point you are subject to mostly active memory requirements, and much
of it likely not in the Java program, so GC is unlikely to help much.
Certainly there is little reason to count on it helping.
Locality of reference does, but that is not guaranteed by a compact heap.
But, doesn't the CG relocate active objects when its compacting the
heap? That's going to affect locality: if active objects are not moved
in virtual memory the GC can only release complete pages as they become
entirely vacant. Additionally its operation would be greatly affected by
the page size, which can vary wildly between operating systems.
Locality of reference is determined by the algorithm patterns, not by heap
compactness. For example, the heap might contain an object at the beginning
that is used with an object at the other end, far enough apart that they are
in separate memory pages even though they are referentially associated. This
is despite the heap being completely compact. There just is no general
correlation between how compact the heap is and how referentially associated
near objects are.
This becomes more of an issue the more memory the program is actively using,
thus the more pages needed to hold everything. AFAIK, the JVM makes no effort
to determine how "close" objects are algorithmically when copying its generations.
--
Lew