[jira] Created: (RVM-861) Refactor bulkCopy optimisations for RVMArray arraycopy's

Refactor bulkCopy optimisations for RVMArray arraycopy's
--------------------------------------------------------

                 Key: RVM-861
                 URL: http://jira.codehaus.org/browse/RVM-861
             Project: RVM
          Issue Type: Improvement
          Components: MMTk
            Reporter: Laurence Hellyer
            Priority: Minor
             Fix For: svn head


Currently objectReferenceBulkCopy is only called by RVMArray.arrayCopy if object array store barriers are required and array load barriers are not required.  This optimisation is not necessarily intuitive and after some conversations Steve Blackburn proposed the following:

{quote}
What I plan to do now is to make mm.Barriers.<type>BulkCopy be called unconditionally whenever the VM needs read or write barriers.   The optimization (as I described below) will then conditionally occur within mm.Barriers.<type>BulkCopy if the GC supports the optimization.  Otherwise the naive (and always correct) element-by-element copy will occur.   However that conditional logic is not visible to the VM code (which happens to only arise in one place: RVMArray).
{/quote}

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

     [ http://jira.codehaus.org/browse/RVM-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Laurence Hellyer updated RVM-861:
---------------------------------

    Attachment: notForTrunk.patch

As part of my RVM-845 primitive write barrier work I created a patch that ensured the primitive bulkCopy methods were called by RVMArray.arrayCopy if array store or load barriers were required.

This patch separates out this refactoring from my last primitive write barrier patch.  I believe Steve has a strong idea of how this refactoring should look, so whilst I don't expect this patch to be applied to trunk I thought I would at least post it (the patch is designed to apply after RVM845-20091005.patch)

Previously bulkCopy methods merely returned a boolean indicating if the mutator made the copy or if RVMarray.arrayCopy had to make the copy.  If the copy was delegated to RVMArray then the copy would be made by a memcopy (assuming non-overlapping src and tgt and correct direction of copy), if the preconditions for memcopy were not met then RVMarray made a element by element copy (which is always safe).  As mentioned in the description of this task, the objectReferenceBulkCopy method was only called if aastore barriers were required (not if aaload barriers were needed).

My patch made the following changes:
* For all array types the corresponding bulkCopy method was called if array store or load barriers were required
* The return type of each mutator bulkCopy was changed to a enum:
 - COPIED - the mutator bulkCopy method made a complete copy (hopefully in an optimised fashion), no further work was required to complete the copy
 - FAST_COPY_SAFE - no further read or write barriers need to be triggered to make a copy (e.g. the objectReferenceBulkCopy method has added the array to a remset for later processing).  Subject to other constraints a direct memcopy of the src to tgt array is safe
 - MUST_SLOW_COPY - the mutator has not made a copy of the array but has indicated that a memcopy is not safe, the array must be copied element by element using array load and array store barriers.

One advantage of this approach is that RVM.arrayCopy methods already contain code to support the MUST_SLOW_COPY case because memcopy is not always applicable.  Mutators which wish the copy to go via a slow element by element copy now do not need to duplicate array copy logic as previously was the case.

Perhaps Steve's refactoring take these issues into account when he has the time.

Kind regards
Laurence

> Refactor bulkCopy optimisations for RVMArray arraycopy's
> --------------------------------------------------------
>
>                 Key: RVM-861
>                 URL: http://jira.codehaus.org/browse/RVM-861
>             Project: RVM
>          Issue Type: Improvement
>          Components: MMTk
>            Reporter: Laurence Hellyer
>            Priority: Minor
>             Fix For: svn head
>
>         Attachments: notForTrunk.patch
>
>
> Currently objectReferenceBulkCopy is only called by RVMArray.arrayCopy if object array store barriers are required and array load barriers are not required.  This optimisation is not necessarily intuitive and after some conversations Steve Blackburn proposed the following:
> {quote}
> What I plan to do now is to make mm.Barriers.<type>BulkCopy be called unconditionally whenever the VM needs read or write barriers.   The optimization (as I described below) will then conditionally occur within mm.Barriers.<type>BulkCopy if the GC supports the optimization.  Otherwise the naive (and always correct) element-by-element copy will occur.   However that conditional logic is not visible to the VM code (which happens to only arise in one place: RVMArray).
> {/quote}

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

     [ http://jira.codehaus.org/browse/RVM-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Grove updated RVM-861:
----------------------------

    Fix Version/s:     (was: svn head)
                   3.1.1

> Refactor bulkCopy optimisations for RVMArray arraycopy's
> --------------------------------------------------------
>
>                 Key: RVM-861
>                 URL: http://jira.codehaus.org/browse/RVM-861
>             Project: RVM
>          Issue Type: Improvement
>          Components: MMTk
>            Reporter: Laurence Hellyer
>            Priority: Minor
>             Fix For: 3.1.1
>
>         Attachments: notForTrunk.patch
>
>
> Currently objectReferenceBulkCopy is only called by RVMArray.arrayCopy if object array store barriers are required and array load barriers are not required.  This optimisation is not necessarily intuitive and after some conversations Steve Blackburn proposed the following:
> {quote}
> What I plan to do now is to make mm.Barriers.<type>BulkCopy be called unconditionally whenever the VM needs read or write barriers.   The optimization (as I described below) will then conditionally occur within mm.Barriers.<type>BulkCopy if the GC supports the optimization.  Otherwise the naive (and always correct) element-by-element copy will occur.   However that conditional logic is not visible to the VM code (which happens to only arise in one place: RVMArray).
> {/quote}

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

     [ http://jira.codehaus.org/browse/RVM-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Blackburn resolved RVM-861.
---------------------------------

    Resolution: Fixed

I have committed a refactoring in r15794.   It is somewhat different to what Laurence has done.

> Refactor bulkCopy optimisations for RVMArray arraycopy's
> --------------------------------------------------------
>
>                 Key: RVM-861
>                 URL: http://jira.codehaus.org/browse/RVM-861
>             Project: RVM
>          Issue Type: Improvement
>          Components: MMTk
>            Reporter: Laurence Hellyer
>            Priority: Minor
>             Fix For: 3.1.1
>
>         Attachments: notForTrunk.patch
>
>
> Currently objectReferenceBulkCopy is only called by RVMArray.arrayCopy if object array store barriers are required and array load barriers are not required.  This optimisation is not necessarily intuitive and after some conversations Steve Blackburn proposed the following:
> {quote}
> What I plan to do now is to make mm.Barriers.<type>BulkCopy be called unconditionally whenever the VM needs read or write barriers.   The optimization (as I described below) will then conditionally occur within mm.Barriers.<type>BulkCopy if the GC supports the optimization.  Otherwise the naive (and always correct) element-by-element copy will occur.   However that conditional logic is not visible to the VM code (which happens to only arise in one place: RVMArray).
> {/quote}

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues