You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Aleksey Shipilev (JIRA)" <ji...@apache.org> on 2007/08/31 12:48:30 UTC
[jira] Created: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
[drlvm][jni] JNI transition uses ineffective TLS get
----------------------------------------------------
Key: HARMONY-4705
URL: https://issues.apache.org/jira/browse/HARMONY-4705
Project: Harmony
Issue Type: Improvement
Components: DRLVM
Reporter: Aleksey Shipilev
For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost there, eliminating up to 30 push/pops and 9 calls.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-4705:
--------------------------------------
Attachment: JNI-tls-1.patch
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524323 ]
Sergey Dmitriev commented on HARMONY-4705:
------------------------------------------
FYI: unfortunately Oracle Application Server's startup is not OK with the JNI-tls-1.patch. It hangs up, quote:
--------
07/09/02 10:26:42 Start process
--------
GC use large pages.
WARNING: Cannot cleanup application URLStreamHandlers.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky reassigned HARMONY-4705:
------------------------------------------
Assignee: Gregory Shimansky
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Assignee: Gregory Shimansky
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch, JNI-tls-3.patch, JNI-tls-4.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-4705:
--------------------------------------
Description:
For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
JNI microtest (calling several millions of empty JNI methods) testifies this:
$ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
iteration: 0 millis:8763
iteration: 1 millis:8722
iteration: 2 millis:8833
$ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
iteration: 0 millis:6780
iteration: 1 millis:6689
iteration: 2 millis:6870
was:
For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost there, eliminating up to 30 push/pops and 9 calls.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524494 ]
Aleksey Shipilev commented on HARMONY-4705:
-------------------------------------------
Good catch, Sergey, thanks! That's due to implementation of helper for Linux/ia32. Please see HARMONY-4723 for the details. Together HARMONY-4723 and this issue work fine on Linux/ia32.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-4705:
--------------------------------------
Attachment: JNI-tls-2.patch
JNI-tls-2.patch
Patch updated for the current state of TM.
VM_thread is now equal to hythread, no additional dereference needed.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-4705:
--------------------------------------
Comment: was deleted
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch, JNI-tls-3.patch, JNI-tls-4.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky resolved HARMONY-4705.
----------------------------------------
Resolution: Fixed
Fix Version/s: 5.0M6
The patch is integrated at 646828. Should there be the same optimization for x86_64 architecture?
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Assignee: Gregory Shimansky
> Fix For: 5.0M6
>
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch, JNI-tls-3.patch, JNI-tls-4.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524146 ]
Aleksey Shipilev commented on HARMONY-4705:
-------------------------------------------
On the Dacapo benchmark attached patch gives boosts on jython (~10%), antlr (~7%), pmd(~5%) @ 2xWoodcrest, Windows x86.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-4705:
--------------------------------------
Comment: was deleted
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch, JNI-tls-3.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-4705:
--------------------------------------
Attachment: JNI-tls-4.patch
JNI-tls-4.patch
Patch for current state of DRLVM.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch, JNI-tls-3.patch, JNI-tls-4.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-4705:
--------------------------------------
Attachment: JNI-tls-3.patch
JNI-tls-3.patch
Clean patch for current state of DRLVM.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch, JNI-tls-3.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4705) [drlvm][jni] JNI transition uses
ineffective TLS get
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587533#action_12587533 ]
Aleksey Shipilev commented on HARMONY-4705:
-------------------------------------------
This patch is clean and can be committed.
> [drlvm][jni] JNI transition uses ineffective TLS get
> ----------------------------------------------------
>
> Key: HARMONY-4705
> URL: https://issues.apache.org/jira/browse/HARMONY-4705
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Aleksey Shipilev
> Attachments: JNI-tls-1.patch, JNI-tls-2.patch
>
>
> For now, JNI transition uses ineffective scheme of TLS getting - it is done via several recursive calls, finally reaching hythread_self().
> The idea is to inline helper for TLS get instead of calling get_thread_ptr_stub(). Disassembly shows that 10 push/pops and 3 calls are completely eliminated there, keeping in mind that TLS get occurs at least 3 times on each JNI transition this give us a huge boost, eliminating up to 30 push/pops and 9 calls.
> JNI microtest (calling several millions of empty JNI methods) testifies this:
> $ ../../Builds/Harmony-clean/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:8763
> iteration: 1 millis:8722
> iteration: 2 millis:8833
> $ ../../Builds/Harmony-fastTLS-1/bin/java -cp . -Xmx128m -Xms128m nalog.nalog
> iteration: 0 millis:6780
> iteration: 1 millis:6689
> iteration: 2 millis:6870
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.