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

2009/3/2 Tony Hosking <hosking@...>

Hi Ian,

This all seems like window-dressing (pardon the pun) to me.  What difference does it make what the operations are called?  Every OS will require some sort of adaptation layer to meet the needs of MMTk.  To my Unix-blinkered mind the current naming scheme seems intuitive.  Or perhaps you are trying to say that there is a deeper problem of mapping the MMTk abstractions to the underlying OS (in other words, I may be missing the point).

Antony Hosking | Associate Professor | Computer Science | Purdue University

305 N. University Street | West Lafayette | IN 47907 | USA

Office +1 765 494 6001 | Mobile +1 765 427 548

Where Harmony goes beyond our current abstractions is that it is much more rigorous. For example, memory pools are used to manage malloc/free. By following their portability library we get the ability to be a 1st class VM wrt integrating with applet viewers, launchers, etc. Currently Jikes RVM doesn't look like a regular Java VM, implemented through a jvm.dll, etc. This is all logged through the trackers and is a long standing problem.

The reserve, commit, decommit, free strategy is fundamentally different to the current mmap, mprotect, munmap strategy. With the mmap strategy we don't have the ability to mark memory as being reserved but not yet in use. Without being able to reserve memory we are not a good citizen with the OS and we frequently get libraries and the like mapped into the MMTk managed address space. The consequence of this is that MMTk can only support heaps smaller than the address space and Jikes RVM breaks when a Linux vendor changes the memory layout (we had a spate of these during the 2.4 releases).

Whilst it is possible to emulate the Harmony behaviour partially on the Linux calls (the notion of commit/decommit is particular to Windows and decommit is a nop on Linux) imo you end up with an ugly API, especially when you need to put it on top of Windows. Harmony have solved this problem already with their portability library and this is being used as the basis for IBM J9 (via IBM Hursley) and Intel DRLVM development work (which both include concurrent garbage collectors, etc.).

By effectively having system calls as our own portability library we are always having to do leg work. We had to work constantly, me in particular (and Steven Augurt before me), doing leg work to keep Classpath working with the RVM as we were a special case (see syswrap and portable native sync in particular). If we can be a special case as little as possible it is inevitable that the development effort will be less.

Ian
 

On 2 Mar 2009, at 08:17, 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

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