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

> 2009/3/2 Daniel Frampton <zyridium@...>
>>
>> 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.
>
> My understanding is Harmony's names are designed to align with Windows, so
> you commit or decommit memory and specify protection at the same time. When
> you reserve memory you can specify protection and you can also specify that
> memory should be committed when it is reserved. If you wish to change the
> protection on committed memory you just commit it again with different
> protection.
>
> I think the problems with your proposal are that:
> - there is no way to reserve but not commit memory, which would be a good
> way to stop the problem we get when shared libraries are loaded into memory
> that MMTk thinks it controls.
> - it makes us have to write the OS interface and breaks the advantage of the
> Harmony portability library (portlib).
>
> Ian
>
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
>
>