The Memory Monitor's graph line drawing, it's warn and auto GC features are by no means implemented in a fool proved way. So the graph line for example is only performed as a non buffered drawing, meaning here that it does rescale in a behaving manner to the underlayed grid size, when you maximize/minimize the monitor's view inside Eclipse.
Also the warn and auto GC size handling are only implemented in a simple manner,
so when you are in trouble, you shouldn't trust them to work absolute flawlessly.
Instead you may better manually press the Memory Monitor's GC button ()
to force garbage collection, which always first performs a system finalization
and afterwards a system GC.
Further the Memory Monitor itself also occupies heap memory, when it is processed in it's own thread from inside the Eclipse Workbench. You can see that it refreshes/redraws from time to time, the default used refresh value is setup to 1000 ms, and that it's grid and graph are thus moving periodically. When doing so, the Memory Monitor on every refresh interval determines always again the actual occupied and used heap memory. After some processing time, the older by the Memory Monitor itself previously occupied but no longer used objects are finalized (marked as no longer used and now unreachable) and the next by the Eclipse Workbench automatically performed GC will free up the memory those now null'ed objects had once occupied. This freed up heap memory space will then be again available and used for new allocated objects (thus it will be filled again with new allocated object memory).
However, there are usually also other Eclipse background processes continiously
running and these processes of
course are also occupying some memory, which you would have to consider when you analyze the
shown up memory calculations.
Note that this Memory Monitor is usually not meant as a tool for detecting
memory leaks or the like. For such tasks good memory profilers, which can continiously
showup all running threads, instantiated objects and the memory these occupy,
are much better suited. So a Java profiler with memory leak detection capabilities,
should be the right tool for such tasks.