You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Zhiguo Ge (JIRA)" <ji...@apache.org> on 2008/08/19 13:05:44 UTC
[jira] Created: (HARMONY-5955) Jitrino does not reclaim some unused
memory units during the course of native code generation
Jitrino does not reclaim some unused memory units during the course of native code generation
---------------------------------------------------------------------------------------------
Key: HARMONY-5955
URL: https://issues.apache.org/jira/browse/HARMONY-5955
Project: Harmony
Issue Type: Improvement
Components: DRLVM
Affects Versions: 5.0M6
Environment: Windows XP
Reporter: Zhiguo Ge
Priority: Minor
Fix For: 5.0M6
The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. Less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
The following is an example of Java source code.
static MapEntry successor(MapEntry x) {
if (x.right != null)
return minimum(x.right);
MapEntry y = x.parent;
while (y != null && x == y.right) {
x = y;
y = y.parent;
}
return y;
}
static MapEntry minimum(MapEntry x) {
if(x.left != null)
x = x.left;
return x;
}
A portion of the output native code by codepack() function is as follows:
03B20337 nop
03B20338 xchg ax,ax
03B2033A call 0764035F
03B2033F add esp,4
03B20345 pop esi
03B20346 pop ebp
03B20347 pop ebx
03B20348 ret 0Ch
03B2034B add esp,4
03B20351 pop esi
03B20352 pop ebp
03B20353 pop ebx
03B20354 ret 0Ch
03B20357 add byte ptr [eax],al
03B20359 pop esi
03B2035A pop ebp
03B2035B pop ebx
03B2035C ret 0Ch
03B2035F add esp,4
03B20365 pop esi
03B20366 pop ebp
03B20367 pop ebx
03B20368 ret 0Ch
The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
3.4% memory requirement reduction for the example shown above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5955) Jitrino does not reclaim some
unused memory units during the course of native code generation
Posted by "Zhiguo Ge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624245#action_12624245 ]
Zhiguo Ge commented on HARMONY-5955:
------------------------------------
Hi, Aleksey, I have updated the patch which was generated by using command diff -uwb.
Thanks!
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5955) Jitrino does not reclaim some unused
memory units during the course of native code generation
Posted by "Zhiguo Ge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhiguo Ge updated HARMONY-5955:
-------------------------------
Attachment: patch.txt
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5955) Jitrino does not reclaim some
unused memory units during the course of native code generation
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623637#action_12623637 ]
Aleksey Shipilev commented on HARMONY-5955:
-------------------------------------------
Hi,
Could you please generate the patch in unified format?
"diff -uwb" should be fine.
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5955) Jitrino does not reclaim some unused
memory units during the course of native code generation
Posted by "Zhiguo Ge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhiguo Ge updated HARMONY-5955:
-------------------------------
Description:
The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
The following is an example of Java source code.
static MapEntry successor(MapEntry x) {
if (x.right != null)
return minimum(x.right);
MapEntry y = x.parent;
while (y != null && x == y.right) {
x = y;
y = y.parent;
}
return y;
}
static MapEntry minimum(MapEntry x) {
if(x.left != null)
x = x.left;
return x;
}
A portion of the output native code by codepack() function is as follows:
03B20337 nop
03B20338 xchg ax,ax
03B2033A call 0764035F
03B2033F add esp,4
03B20345 pop esi
03B20346 pop ebp
03B20347 pop ebx
03B20348 ret 0Ch
03B2034B add esp,4
03B20351 pop esi
03B20352 pop ebp
03B20353 pop ebx
03B20354 ret 0Ch
03B20357 add byte ptr [eax],al
03B20359 pop esi
03B2035A pop ebp
03B2035B pop ebx
03B2035C ret 0Ch
03B2035F add esp,4
03B20365 pop esi
03B20366 pop ebp
03B20367 pop ebx
03B20368 ret 0Ch
The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
3.4% memory requirement reduction for the example shown above.
was:
The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. Less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
The following is an example of Java source code.
static MapEntry successor(MapEntry x) {
if (x.right != null)
return minimum(x.right);
MapEntry y = x.parent;
while (y != null && x == y.right) {
x = y;
y = y.parent;
}
return y;
}
static MapEntry minimum(MapEntry x) {
if(x.left != null)
x = x.left;
return x;
}
A portion of the output native code by codepack() function is as follows:
03B20337 nop
03B20338 xchg ax,ax
03B2033A call 0764035F
03B2033F add esp,4
03B20345 pop esi
03B20346 pop ebp
03B20347 pop ebx
03B20348 ret 0Ch
03B2034B add esp,4
03B20351 pop esi
03B20352 pop ebp
03B20353 pop ebx
03B20354 ret 0Ch
03B20357 add byte ptr [eax],al
03B20359 pop esi
03B2035A pop ebp
03B2035B pop ebx
03B2035C ret 0Ch
03B2035F add esp,4
03B20365 pop esi
03B20366 pop ebp
03B20367 pop ebx
03B20368 ret 0Ch
The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
3.4% memory requirement reduction for the example shown above.
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5955) Jitrino does not reclaim some unused
memory units during the course of native code generation
Posted by "Zhiguo Ge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhiguo Ge updated HARMONY-5955:
-------------------------------
Attachment: patch.txt
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. Less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-5955) Jitrino does not reclaim some
unused memory units during the course of native code generation
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chunrong Lai reassigned HARMONY-5955:
-------------------------------------
Assignee: Chunrong Lai
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Assignee: Chunrong Lai
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5955) Jitrino does not reclaim some unused
memory units during the course of native code generation
Posted by "Zhiguo Ge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhiguo Ge updated HARMONY-5955:
-------------------------------
Comment: was deleted
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5955) Jitrino does not reclaim some unused
memory units during the course of native code generation
Posted by "Zhiguo Ge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhiguo Ge updated HARMONY-5955:
-------------------------------
Attachment: (was: patch.txt)
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-5955) Jitrino does not reclaim some
unused memory units during the course of native code generation
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chunrong Lai resolved HARMONY-5955.
-----------------------------------
Resolution: Fixed
Fix Version/s: (was: 5.0M6)
5.0M8
Patch applied in r709880.
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Assignee: Chunrong Lai
> Priority: Minor
> Fix For: 5.0M8
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5955) Jitrino does not reclaim some
unused memory units during the course of native code generation
Posted by "Zhiguo Ge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624248#action_12624248 ]
Zhiguo Ge commented on HARMONY-5955:
------------------------------------
Hi, Aleksey , I have updated the patch with the one generated by using "diff -uwb" .
Thanks!
> Jitrino does not reclaim some unused memory units during the course of native code generation
> ---------------------------------------------------------------------------------------------
>
> Key: HARMONY-5955
> URL: https://issues.apache.org/jira/browse/HARMONY-5955
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Affects Versions: 5.0M6
> Environment: Windows XP
> Reporter: Zhiguo Ge
> Priority: Minor
> Fix For: 5.0M6
>
> Attachments: patch.txt
>
>
> The CodeEmitter::emitCode( void ) function will generate native code from LIR without solving the target addresses of branch instructions. The codepack() function in Jitrino will resolve the target addresses and make native code smaller. As a result, less momory units are required for storing the native code after codepack() . However, Jitrino still allocates more than enough memory units for storing the native code.
> The following is an example of Java source code.
> static MapEntry successor(MapEntry x) {
> if (x.right != null)
> return minimum(x.right);
> MapEntry y = x.parent;
> while (y != null && x == y.right) {
> x = y;
> y = y.parent;
> }
> return y;
> }
> static MapEntry minimum(MapEntry x) {
> if(x.left != null)
> x = x.left;
> return x;
> }
> A portion of the output native code by codepack() function is as follows:
> 03B20337 nop
> 03B20338 xchg ax,ax
> 03B2033A call 0764035F
> 03B2033F add esp,4
> 03B20345 pop esi
> 03B20346 pop ebp
> 03B20347 pop ebx
> 03B20348 ret 0Ch
> 03B2034B add esp,4
> 03B20351 pop esi
> 03B20352 pop ebp
> 03B20353 pop ebx
> 03B20354 ret 0Ch
> 03B20357 add byte ptr [eax],al
> 03B20359 pop esi
> 03B2035A pop ebp
> 03B2035B pop ebx
> 03B2035C ret 0Ch
> 03B2035F add esp,4
> 03B20365 pop esi
> 03B20366 pop ebp
> 03B20367 pop ebx
> 03B20368 ret 0Ch
> The instructions from 03B20357 to 03B20368 are not used by any places while they still occupy memory entries.
> Our patch is to make Jitrino allocate exact demanded size of memory units for storing generated native code. Experiment result shows
> 3.4% memory requirement reduction for the example shown above.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.