| Key: |
RVM-435
|
| Type: |
Improvement
|
| Status: |
Closed
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Ian Rogers
|
| Reporter: |
Ian Rogers
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Related
|
|
This issue relates to:
|
|
RVM-434
Performance regression due to string handling
|
|
|
|
|
|
|
|
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.
|
|
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. |
Show » |
Sort Order:
|
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.