Re: [rvm-core] Renaming/aligning methods in org.mmtk.vm.Memory with Harmony?

I think this is just a question of priorities. Any change like this we
make obviously introduces the possibility of performance and stability
problems. As Eliot says, I think it makes sense to tie freeing virtual
memory to the heap shrinking logic. However, heap growth/shrinking in
general is not something that has got a huge amount of attention in
MMTk. When comparing individual collectors we usually take it out of
the picture entirely by evaluating across a range of fixed heap sizes.

Of course for research in other areas this is not the case, and
contributions of any improvements to our heap resizing logic could
both improve the default behavior of Jikes RVM, as well as assist
future research.

On the separate question of changing the names for the virtual memory
functions, I really don't think it is a good idea. The operations we
have are fairly simple and I would argue quite obvious from the names
(or at least javadoc).

I think you have also misunderstood what the protection methods do
anyway. We want to be able to actually control memory protection
(read/write/execute) to both support collectors and help debugging.
Currently we support protecting and then unprotecting memory. This is
different to decommitting memory, which if I understand correctly
means the physical storage is thrown away.

Under windows... I think we would want:

dzmmap -> VirtualAlloc (reserve + commit)
mprotect -> VirtualProtect
munprotect -> VirtualProtect
munmap -> VirtualFree (decommit + unreserve)

Under harmony, I don't know what the equivalent calls are. Maybe
harmony does not provide the same level of access to memory
protection.

Cheers,
Daniel.

On Mon, Mar 2, 2009 at 9:27 AM, Eliot Moss <moss@...> wrote:
> 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
>

------------------------------------------------------------------------------
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