[jira] Created: (RVM-845) Primitive write barrier support

Primitive write barrier support
-------------------------------

                 Key: RVM-845
                 URL: http://jira.codehaus.org/browse/RVM-845
             Project: RVM
          Issue Type: New Feature
          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
            Reporter: Laurence Hellyer
         Attachments: primitiveWriteBarriers.patch, statementOfContribution.txt

Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.

Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.

As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).

In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
 * Address.store can now store a boolean with optional offset
 * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
 * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset

It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
 a) preserving type safety is important
 b) it improves readability of the code
 c) this technique allows for accounting by type
 d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)

The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.

Quick performance numbers:

The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:

Benchmark: Relative overhead with patch applied:
Antlr 1.002
Bloat 1.005
Fop        1.003
Hsqldb        0.984
Jython 1.005
Luindex 1.011
Lusearch 1.002
Pmd 0.997
Xalan 1.008

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

       

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=184981#action_184981 ]

David Grove commented on RVM-845:
---------------------------------

Thanks, looks like a nice addition!

I took a quick scan through the "rvm" part of the patch.  It looked plausible to me, with the exception of the addition of the CHAR_ASTORE operator for the opt compiler.  Since the sign/zero extension doesn't matter for stores, we uniformly collapse the signed/unsigned version of the store operations into a single operator.  BURS still should be able to avoid sign extension for the store(load(x)) pattern (perhaps there is just a missing rule somewhere??).

Steve/Daniel, could one of you take a look at the MMTk part of the patch and comment?  I don't mind doing the leg work of committing it and changing the opt compiler part to drop CHAR_ASTORE, but I want one of you to sign off on the MMTk changes first.

thanks,

--dave

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>         Attachments: primitiveWriteBarriers.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

       

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

[Laurence Hellyer]

On 27 Jul 2009, at 14:23, David Grove (JIRA) wrote:

>
>    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=184981#action_184981 
>  ]
>
> David Grove commented on RVM-845:
> ---------------------------------
>
> Thanks, looks like a nice addition!
>
> I took a quick scan through the "rvm" part of the patch.  It looked  
> plausible to me, with the exception of the addition of the  
> CHAR_ASTORE operator for the opt compiler.  Since the sign/zero  
> extension doesn't matter for stores, we uniformly collapse the  
> signed/unsigned version of the store operations into a single  
> operator.  BURS still should be able to avoid sign extension for the  
> store(load(x)) pattern (perhaps there is just a missing rule  
> somewhere??).

Hi Dave,

Thanks for the (positive) comments...

The new CHAR_ASTORE operator was introduced so that in  
ExpandRuntimesServices we can differentiate between a short array  
store and char array store and invoke the appropriate primitive write  
barrier (based on Java type rather than field size).  Did you have an  
alternative mechanism in mind for this (or have I done something  
horribly stupid...?)

Kind regards
Laurence

Laurence Hellyer
Research Student
Computing Laboratory
University of Kent

More info: http://www.cs.kent.ac.uk/people/rpg/lh243/


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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185037#action_185037 ]

David Grove commented on RVM-845:
---------------------------------

I think you can handle the CHAR vs. SHORT ASTORE by in ExpandRuntimeServices getting the store instructions LocationOperand (AStore.getLocation())  and then getting the arrayElementType from it to distinguish between shorts and chars to figure out what to call.  A little more cumbersome in the expansion code, but it avoids introducing an operator and is more consistent with how we are doing other store operations (byte vs. ubyte, etc).

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>         Attachments: primitiveWriteBarriers.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

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

Laurence Hellyer updated RVM-845:
---------------------------------

    Attachment: primitiveWriteBarriersV2.patch

Following Dave's comments this patch removes the need for a CHAR_ASTORE operator by getting the element type for 16 bit array stores

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>         Attachments: primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

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

David Grove updated RVM-845:
----------------------------

    Fix Version/s: 3.1.1

Any feedback from the MMTk side on this patch?

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>             Fix For: 3.1.1
>
>         Attachments: primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186322#action_186322 ]

Steve Blackburn commented on RVM-845:
-------------------------------------

I'm afriad we've not had a chance to take a very deep look, which is what we'll need.

We've had our backs to the wall for a few weeks thanks to the ASPLOS deadline.   Then one of us will give it a good look.

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>             Fix For: 3.1.1
>
>         Attachments: primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187478#action_187478 ]

Steve Blackburn commented on RVM-845:
-------------------------------------

Daniel and I have both had a look.

1.  We don't want to commit it without a configuration from which we can build a straightforward test for it---we don't want it in the head untested.   Laurence, you say above that you have a configuration that depends on this patch.   Is it suitable as the basis for a regression test?   Can you make this available to us please?

2.  We'd like to clean up the API for barriers (into MMTk and MemoryManager).   I'll try to do that over the next day or so .

3.  Hopefully with the above fixed we can have this patch committed soon.

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>             Fix For: 3.1.1
>
>         Attachments: primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188183#action_188183 ]

Laurence Hellyer commented on RVM-845:
--------------------------------------

Hi Steve and Daniel,

Thanks for taking a look at this.  In response to your comments:

1) Currently I have two patches that provide some sort of testing for primitive write barriers (although I don't believe either are suitable):

i) A GC that extends SemiSpace and declares the needsPrimitiveWriteBarriers constraint.  The mutator class provides primitive write barriers which make a straight write to the heap.  The rest of the GC is deferred to the parent classes.  This test checks that the primitive write barrier code compiles but does not provide any assurances that the compiler has not optimised away parts of the barrier.  There's no reason this test couldn't work with say the Immix collector and I'm happy to contribute the patch, but I think its only of very limited value.

ii) Steve, we discussed my second patch briefly at ISMM09 and is much more intrusive - making the default allocation space be READ_ONLY.  All primitive and reference writes to the heap occur via a mmap'd page aliased to the heap.  Unfortunately this impacts code in BumpPointer, MonotonePageResource and a whole load of other places that store metadata directly into the heap.  This patch provides very strong reassurances that barriers are correctly compiled but execution speed is too slow to be useful as a regression test.

Having thought about this I think a more suitable test would be as follows:

* A simple Java application (PrimitiveWriteBarrierTestApplication) that declares a public volatile field for each primitive type
* Add a pickAllocator(byte[]) method to Plan that receives a byte array describing the type to be allocated, this method should return ALLOC_DEFAULT
        * Extend MemoryManager.pickAllocator(RVMType) to call Plan.pickAllocator(byte[]) - giving individual GC plans a mechanism to control where allocation should happen
* Add a new PrimitiveWriteBarrierTest GC plan - this plan can extend the NoGC plan or any other GC plan, extending a Plan that actually does GC will allow this test to run normal benchmarks
        * This plan should instantiate an additional space (PrimitiveWriteBarrierTestApplicationSpace)
        * This plan should override pickAllocator(type[]) and alloc() such that the PrimitiveWriteBarrierTestApplication class is allocated into the dedicated PrimitiveWriteBarrierTestApplicationSpace, this space should only be for this type, all other objects should be allocated into their normal space
        * The plan should declare the needsPrimitiveWriteBarriers constraint and provide a suitable implementation
                * If the object is in any space other than the PrimitiveWriteBarrierTestApplicationSpace - perform the primitive write as normal
                * If writing to the PrimitiveWriteBarrierTestApplicationSpace then manipulate the value before storing it (maybe add 1, maybe complement)
* The PrimitiveWriteBarrierTestApplication performs a series of writes to its primitive fields and then reads the fields back, the test expects to read back a different value to the value written (the fields need to be marked volatile to ensure the opt compiler doesn't just remove the read).  If the read value does not match the expected value then either the test is being run under a different GC plan, or the barrier code is faulty.

This approach provides a stronger assurance that the primitive write barriers are being correctly compiled than the first suggested patch.  It does not catch all primitive writes to the heap like the second patch, but does handle the desired case of putfield's.

I have not yet implemented this patch (although it's not a lot of work) - I thought I would suggest it first to make sure that it would be an acceptable test case.  If you have any alternative suggestions then it would be great to discuss their relative merits and come to a consensus.  I'm quite happy to write the test case once it's agreed on how we should test this.

2) You commented on tidying up the API for barriers - as best I remember I followed the current API for reference barriers when adding the necessary primitive write barrier code.  Whilst I have no objections to refactoring the code I am just curious if I messed something up or if this patch provides a convenient point for some wider MMTk and MemoryManager refactoring?

3) Great!

Kind regards
Laurence

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>             Fix For: 3.1.1
>
>         Attachments: primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188383#action_188383 ]

Steve Blackburn commented on RVM-845:
-------------------------------------

Hi Laurence,

w.r.t. 2), no you've done nothing wrong; your patch just highlights that the existing API is creaky.

w.r.t. 1), Daniel has built and tested a nice general system for testing barriers (based on fine grain protection offered by a virtualization layer), which I suggest we move to ASAP.  However, he is not ready to commit this just yet (needs to be tidied, documented and properly integrated) and he's in the final throes of writing up his PhD, so it won't be ready in the near term.   So I suggest that for the short term we go for your more basic (and as you note, more limited) test of a simple SemiSpace collector that happens to utilize these barriers.

As to the overall approach from here, what I want to do right now is:

a) I do some basic re-factoring of the underlying infrastructure into the head ASAP
b) Together we get your system working with the new head
c) We get a basic regression test working
d) We commit b) & c)  :-)
e) Daniel gets his system committed
f) We introduce a comprehensive regression test for all barriers


I want to get to d) ASAP.   Hopefully we'll get to f) within a couple of months.

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>             Fix For: 3.1.1
>
>         Attachments: primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

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

Laurence Hellyer updated RVM-845:
---------------------------------

    Attachment: usePrimitiveWriteBarriers.patch

Hi Steve,

Please find attached a simplistic test collector (extending SS) that uses primitive write barriers to write into the heap

We need to decide what an appropriate regression test is - probably nothing more than checking that both the Base and Opt builds compile and maybe run _200_check correctly?

I look forward to you committing your refactoring.  Once your happy with the API in trunk if you could give me a nod and I'll rework my patch.

Kind regards
Laurence

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>             Fix For: 3.1.1
>
>         Attachments: primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

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

Steve Blackburn updated RVM-845:
--------------------------------

    Attachment: 00-barrier-refactor.patch

Here is a first rough stab at the refactoring I'd like to see.

There are really only two substantive changes:

1.  Move barrier code out of MemoryManager into a new Barriers class.

2.  Rationalize the naming of barriers, prefixing reference barriers with "reference" so that this naming convention can be trivially replicated for each of the other types, with the prefix suitably replaced by the type name.

This patch should be pretty close to ready to go.   Aside from some minor cleanup, the only remaining task is to pad it out with stubs for all of the different types.

Laurence: feel free to take a look, but don't bother patching against this yet because it is not final, so you could end up wasting effort.  I hope to have something finalized within a day or two.

Others: please let me know if you'd like to see a different refactoring (I discussed this with Daniel, but will be interested to hear if anyone else has alternative ideas).

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

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

Steve Blackburn reassigned RVM-845:
-----------------------------------

    Assignee: Steve Blackburn

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

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

Steve Blackburn updated RVM-845:
--------------------------------

    Attachment: 01-barrier-refactor.patch

A few minor changes and inclusion of the MMTk harness.   I've not had much luck in testing the harness.  Robin, if you're able to do so, it would be great if you could test this.

I would like to commit this (or something similar) very soon.

The next step is do the trivial cookie-cutter duplication of the code for reference types (included in this patch) to pad out for each of the primitive types.   I want some consensus that I've got it basically right for reference types before doing that, though.

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, 01-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188876#action_188876 ]

Robin Garner commented on RVM-845:
----------------------------------

The MMTk harness works fine with this patch - I've committed a trivial change to test-mmtk to make it less platform sensitive.

My only minor quibble is with the names of the constants INSTANCE_LOAD and INSTANCE_STORE.  I'd prefer GETFIELD and PUTFIELD (consistent with GETSTATIC/PUTSTATIC), but i guess INSTANCE_FIELD_LOAD/STORE would be OK too.

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, 01-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188876#action_188876 ]

Robin Garner edited comment on RVM-845 at 8/27/09 9:12 PM:
-----------------------------------------------------------

The MMTk harness works fine with this patch - I've committed a trivial change to test-mmtk to make it less platform sensitive.

There seems to be a bug/inconsistency in the VM.barriers.wordRead method - the barrier itself takes 5 parameters,  src, slot, metaDataA, metaDataB, mode, but the wordRead method doesn't have the slot parameter and assumes that metadataA is the slot.  Given that the metadata is a workaround, I think the slot parameter should be explicit, but in either case the Poisoned collector is broken.

One minor quibble is with the names of the constants INSTANCE_LOAD and INSTANCE_STORE.  I'd prefer GETFIELD and PUTFIELD (consistent with GETSTATIC/PUTSTATIC), but i guess INSTANCE_FIELD_LOAD/STORE would be OK too.

      was (Author: rgarner):
    The MMTk harness works fine with this patch - I've committed a trivial change to test-mmtk to make it less platform sensitive.

My only minor quibble is with the names of the constants INSTANCE_LOAD and INSTANCE_STORE.  I'd prefer GETFIELD and PUTFIELD (consistent with GETSTATIC/PUTSTATIC), but i guess INSTANCE_FIELD_LOAD/STORE would be OK too.
 

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, 01-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188920#action_188920 ]

Steve Blackburn commented on RVM-845:
-------------------------------------

THanks Robin.

I don't think the methods are inconsistent, although they did need cleaning up.   In the case of the harness, we use one of the available metadata parameters to pass the slot, which is not required in the Jikes RVM case.

One thing that is perhaps slightly mysterious is that we no longer have writes to statics as a special case of the other writes, but rather we have a separate API "nonHeap**" which is used for such read and writes, and more generally for any reads or writes to non-heap regions that needs to be barriered (perhaps a stack barrier, for example).   This API takes a slot rather than a reference as the argument.  

The underlying theme above is to move MMTk away from strong binding to Java, so we no longer use "putfield/getfield" etc on the MMTk end, though we do on the Jikes RVM end.

Furthermore, on the Jikes RVM end we separate out the possibilty of generic VM barriers from GC-required barriers.  There are cases where the VM may require a barrier for purposes that don't relate to the GC.   This is now pretty cleanly expressed.

Your comment about the GETSTATIC etc variables is valid, it was an oversight.  Fixed now.

I've gone ahead and committed, but if anyone is unhappy or can see clear points for improvement, just shout and we can fix it up.

Once everyone is content, I'll do the process of expanding the API out to all the primitive types, which will now be trivial cookie cutter work.

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, 01-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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

    [ http://jira.codehaus.org/browse/RVM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191553#action_191553 ]

Steve Blackburn commented on RVM-845:
-------------------------------------

Laurence, I believe that I have finally finished all the re-working of the plumbing (see RVM-589).

If you're able, could you please post a new patch relative to the head?

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, 01-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

--
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-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Laurence Hellyer updated RVM-845:
---------------------------------

    Attachment: RVM845-20091003.patch

Hi,

Please find attached a new version of my patch designed to apply to trunk.

Steve: I have since thought about the BulkCopy changes we discussed and have taken the liberty of implementing one possible refactoring (see details below).  If this change is completely inappropriate then I can revert it from the patch before it is applied - otherwise the patch could be applied to trunk and then any small tweaks committed later.

Begin possible commit message:

This patch completes compiler support for primitive write barriers (see RVM-845 and RVM-859) and adds a simplistic MMTk collector that uses primitive write barriers:

* Add Baseline and Opt compiler support for write barriers on primitive putfields and primitive array stores (ppc and ia32)
* Add a new MMTk collector that extends SemiSpace and uses primitive write barriers - this collector provides some simplistic assurances that the primitve write barrier code is correct
* Add locationMetadata to various Magic methods and update code to pass this metadata when known
* Object cloning, field reflection, sun.misc.Unsafe.* and Synchrornization code has been updated to use primitive write barriers when required
* Support for atomic exchange of int, long and Word fields when either field stores or reads requires a barrier
* Fix some Javadoc errors introduced during the recent MMTk refactoring

The final change that this patch makes is the handling of <type>BulkCopy.  Previously objectReferenceBulkCopy was only called by RVMArray.arrayCopy if object array store barriers were required and array load barriers were not required.  In a conversation with Steve Blackburn and Daniel Frampton it was agreed that this optimisation was not necessarily intuative and it was agreed that BulkCopy should be unconditionally called if either a array load or store barrier was required.  This patch refactors all BulkCopy methods so that they are called during an array copy if a store or load barrier is required.  The refactored BulkCopy methods use a enum to encode the return value and encode how the array copy should be made.  Current possible return values are:

BulkCopyState.COPIED - the mutator BulkCopy method made a copy of the array (hopefully in an optimised fashion), no further work is required
BulkCopyState.FAST_COPY_STATE - no further barriers need to be triggered during the actual copy, it is safe to attempt an memcopy of the target to destination array (if conditions about memcopy are met)
BulkCopyState.MUST_SLOW_COPY - array copy must be by made reading and writing each array element, it is not safe to attempt a memcopy

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, 01-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, RVM845-20091003.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

--
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-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=193329#action_193329 ]

Steve Blackburn commented on RVM-845:
-------------------------------------

Thanks for the patch Laurence.

As I discussed with you in response to your prior email (should have been here rather than email), I am planning to refactor bulk copy, and I will still do so---I established what I think is the right solution and will update the code as soon as I can.

{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).

I hope to do that over the next few days if possible (had hoped to do it today but am hopelessly behind on other things).   However, you should feel free to just go and refactor your patch against the existing code.   I'm happy to do my fixes after your patch comes in if you beat me to it (ie I'll "fix" your code for you if I've not done the refactoring before you get yours done).
{quote}

Also, I want to keep that particular change out of your patch because it is a separate concern.   I hope to have it done in the next few days.

> Primitive write barrier support
> -------------------------------
>
>                 Key: RVM-845
>                 URL: http://jira.codehaus.org/browse/RVM-845
>             Project: RVM
>          Issue Type: New Feature
>          Components: Compiler: Baseline, Compiler: Optimizing, MMTk
>            Reporter: Laurence Hellyer
>            Assignee: Steve Blackburn
>             Fix For: 3.1.1
>
>         Attachments: 00-barrier-refactor.patch, 01-barrier-refactor.patch, primitiveWriteBarriers.patch, primitiveWriteBarriersV2.patch, RVM845-20091003.patch, statementOfContribution.txt, usePrimitiveWriteBarriers.patch
>
>
> Certain classes of garbage collection require write barriers on primitives as well as references.  This patch adds the required support to JikesRVM and MMTk for primitive write barriers on both Intel and PowerPC using either the Baseline or Opt compiler.
> Specifically this patch adds support for write barriers on primitive putfields and primitive array stores.  Object cloning and reflection code has been updated to use primitive write barriers as required.  A separate patch can be made available that provides a collector that demonstrates using primitive write barriers if desired.
> As would be expected, applying this patch to trunk (r15745) results in no measurable slowdown to configurations that do not require primitive write barriers - the optimising compiler removes all primitive write barrier specific code (detailed measurements below).
> In adding primitive write barriers to the compilers, a number of enhancements were made to Magic operations that should be of benefit to all users:
>  * Address.store can now store a boolean with optional offset
>  * Added Magic.setFloatAtOffset and setBooleanAtOffset (with optional locationMetadata)
>  * Optional locationMetadata argument for Magic.setByteAtOffset, setCharAtOffset, setShortAtOffset, setLongAtOffset, setDoubleAtOffset and setIntAtOffset
> It was decided to use the Java type system to provide a separate MMTk write barrier for each Java type (char, short etc.) rather than abuse the type system by having a different barrier for each field size (byte, short, word and double word).  Whilst this approach leads to a larger patch, we believe that:
>  a) preserving type safety is important
>  b) it improves readability of the code
>  c) this technique allows for accounting by type
>  d) as the barriers are inlined, the runtime cost to the compiler of extra barrier methods will be small and there should be no additional mutator overhead (although this has not been measured)
> The code styles for the IA32 and PowerPC compilers are very different and this patch attempts to implement the primitive write barriers in a native style for each compiler.  Where possible helper methods have been used to reduce the size of code and reduce boiler plate.  For a change of this size I fully support a review of the code and it being signed off by the compiler maintainers before it enters trunk.
> Quick performance numbers:
> The performance of a clean checkout of trunk was compared to the performance of trunk with the patch applied on a number of ia32 machines.  Each benchmark was run with 3x minimum heap for 6 iterations within a single RVM invocation, this was repeated for a total of 5 invocations per build/benchmark.  A compiler advice file was used to keep the compiler workload constant and the machines had their networks down.  The geomean of total execution time for each build/benchmark was calculated and used to calculate the overhead between builds:
> Benchmark: Relative overhead with patch applied:
> Antlr 1.002
> Bloat 1.005
> Fop        1.003
> Hsqldb        0.984
> Jython 1.005
> Luindex 1.011
> Lusearch 1.002
> Pmd 0.997
> Xalan 1.008

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