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

> My windows comment was about logically what methods could be called,
> not a suggestion to code to it directly.
>
> it seems to me that it is trivial to implement the primitives we
> currently require in terms of AIX, linux, harmony, or windows
> directly.
>
> Cheers,
> Daniel.
>
> On Mon, Mar 2, 2009 at 11:22 AM, Ian Rogers <ian.rogers@...
> > wrote:
>> 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
>>
>>
>
> ------------------------------------------------------------------------------
> 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