« Return to Thread: [rvm-core] Renaming/aligning methods in org.mmtk.vm.Memory with Harmony?
Re: [rvm-core] Renaming/aligning methods in org.mmtk.vm.Memory with Harmony?
by Robin Garner
::
Rate this Message:
My feeling is that the names used in the MMTk interface should most
closely align with the effect that MMTk expects, rather than the
implementation on any given platform. I'm not opposed to changing the
operation names, but I don't see that reserve/commit/uncommit expresses
the intended effects any better than dzmmap/mprotect/munprotect.
As you say, there is a simple 1:n mapping between the MMTk interface and
the Harmony abstractions, so I don't see a good reason to change MMTk at
this stage.
Regards,
Robin
Ian Rogers wrote:
> Hi,
>
> I'm interested in the interface to underlying OS operations used by MMTk:
>
> dzmmap - demand zero mmap
> mprotect - remove read/write protections to a region of memory
> munprotect - allow read/write access to a region of memory
>
> the equivalent Harmony interfaces are:
>
> reserve - reserve a region of virtual memory for use
> commit - allow access in a region previously reserved
> uncommit - remove access to a region
>
> for completeness there is unreserve (but MMTk has no munmap).
>
> MMTk's dzmmap is equivalent to a reserve & commit, mprotect to
> uncommit, munprotect to commit. The Harmony interface more directly
> maps to that of Windows. It would make sense to me to push the Harmony
> naming convention through the RVM interface into MMTk's. I will
> provide a patch if other people agree.
>
> Ian
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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
closely align with the effect that MMTk expects, rather than the
implementation on any given platform. I'm not opposed to changing the
operation names, but I don't see that reserve/commit/uncommit expresses
the intended effects any better than dzmmap/mprotect/munprotect.
As you say, there is a simple 1:n mapping between the MMTk interface and
the Harmony abstractions, so I don't see a good reason to change MMTk at
this stage.
Regards,
Robin
Ian Rogers wrote:
> Hi,
>
> I'm interested in the interface to underlying OS operations used by MMTk:
>
> dzmmap - demand zero mmap
> mprotect - remove read/write protections to a region of memory
> munprotect - allow read/write access to a region of memory
>
> the equivalent Harmony interfaces are:
>
> reserve - reserve a region of virtual memory for use
> commit - allow access in a region previously reserved
> uncommit - remove access to a region
>
> for completeness there is unreserve (but MMTk has no munmap).
>
> MMTk's dzmmap is equivalent to a reserve & commit, mprotect to
> uncommit, munprotect to commit. The Harmony interface more directly
> maps to that of Windows. It would make sense to me to push the Harmony
> naming convention through the RVM interface into MMTk's. I will
> provide a patch if other people agree.
>
> Ian
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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
« Return to Thread: [rvm-core] Renaming/aligning methods in org.mmtk.vm.Memory with Harmony?
| Free embeddable forum powered by Nabble | Forum Help |
