Ting Yang's work further suggested the following:
- If running benchmarks more or less standalone, with a known amount of
demand for real memory, etc., it does not make much sense to munmap,
given the overhead of remapping later.
- If running in real life situations under varying load, and using
something like Ting's heap size adjustment, you get better performance
overall if you restrict your usage to the real memory available,
which may sometimes decrease. When this happens, it may be a good idea
to unmap those pages you don't care about, so the OS won't be as
inclined to page out the ones you *do* care about.
In sum, unmapping does not speed up *benchmarks*, so it was never
really explored much and supported. But *real life* probably wants
it there, and algorithms that will actually invoke it. However,
unmapping after each gc remains a bad idea -- one should unmap
when one is reducing the demand for real memory ....
Bottom line: MMTk *should* support it, even if it does not do so
now.
Contrary opinions from down under?
Best wishes -- Eliot
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
