RVM

Don't allocate memory when converting C buffers to Strings or Classes

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.9.2
  • Fix Version/s: 2.9.3
  • Component/s: Runtime
  • Labels:
    None
  • Number of attachments :
    0

Description

In 2.9.2 Jikes RVM when we go from a C malloced buffer to a Java String or Class we first new an array, copy the C malloced buffer into the array and then convert the byte array into the Java type. The memory associated with the array is live just during the conversion. These JNI calls are frequent, the worst case is DaCapo bloat which spends 3.68% of its execution time servicing these JNI calls at 10 iterations. This doesn't include the associated GC overhead in allocating lots of short lived buffers.

Issue Links

Activity

Hide
Ian Rogers added a comment -

r14090, r14091, r14092 and r14093 convert JNI code to encode Strings using direct byte buffers. It uses a UTF8 character set encoder provided by the class library.

r14095 adapts our UTF8 converter to work with byte buffers to avoid using the class library character set encoder which appears to have a performance overhead.

The 8 commits r14096 to r14104 fix a number of issues that meant the direct byte buffers weren't getting aggregate replaced with registers.

Show
Ian Rogers added a comment - r14090, r14091, r14092 and r14093 convert JNI code to encode Strings using direct byte buffers. It uses a UTF8 character set encoder provided by the class library. r14095 adapts our UTF8 converter to work with byte buffers to avoid using the class library character set encoder which appears to have a performance overhead. The 8 commits r14096 to r14104 fix a number of issues that meant the direct byte buffers weren't getting aggregate replaced with registers.
Hide
Ian Rogers added a comment -

r14106 is another commit to fix where we weren't aggregate replacing, this time in the case of going from String to byte buffer (rather than the other way around). This is the likely cause of the performance regression on mtrt and chart.

Show
Ian Rogers added a comment - r14106 is another commit to fix where we weren't aggregate replacing, this time in the case of going from String to byte buffer (rather than the other way around). This is the likely cause of the performance regression on mtrt and chart.
Hide
Ian Rogers added a comment -

Performance results [1] show performance is up or level across the board.

[1] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3379/performance_report

Show
Ian Rogers added a comment - Performance results [1] show performance is up or level across the board. [1] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3379/performance_report

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: