Harmony
  1. Harmony
  2. HARMONY-1949

[drlvm][gc_cc] Refactoring TLS access in GC_CC.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: DRLVM
    • Labels:
      None

      Description

      This patch changes the way GC requests TLS data: Instead of asking VM GC calls to TM directly.

      After the patch is applied GC is able to report static offsets for all TLS fields it uses to JIT

      1. gc_cc_2.diff
        12 kB
        Mikhail Fursov
      2. gc_cc.diff
        12 kB
        Mikhail Fursov

        Issue Links

          Activity

          Hide
          weldon washburn added a comment -

          smoke test passes on windowsxp and linux w/ gcc 4.0.2

          Show
          weldon washburn added a comment - smoke test passes on windowsxp and linux w/ gcc 4.0.2
          Hide
          Ivan Volosyuk added a comment -

          Patch is ok to me now. Good work!

          Show
          Ivan Volosyuk added a comment - Patch is ok to me now. Good work!
          Hide
          Mikhail Fursov added a comment -

          The updated patch.
          gc_supports_frontier_allocation return 'false' now.

          Show
          Mikhail Fursov added a comment - The updated patch. gc_supports_frontier_allocation return 'false' now.
          Hide
          Mikhail Fursov added a comment -

          Could not resist and run the test on SUN and BEA. The results I have on my PC:

          4) Sun 1.5
          Time:2375 o=java.lang.Object@45a877

          5) BEA 1.5
          Time:9375 o=java.lang.Object@2ca699

          Show
          Mikhail Fursov added a comment - Could not resist and run the test on SUN and BEA. The results I have on my PC: 4) Sun 1.5 Time:2375 o=java.lang.Object@45a877 5) BEA 1.5 Time:9375 o=java.lang.Object@2ca699
          Hide
          Mikhail Fursov added a comment -

          Here is a microtest, that shows that there are no performance degradation with this patch:

          public class Test {
          public static void main(String[] args)

          { Test t = new Test(); //resolve and initialize the helper. Needed only for helper inlining. foo2(); }

          public static void foo2() {

          long t1 = System.currentTimeMillis();
          Object o = null;
          for (int i=0;i<400*1000*1000;i++)

          { o = new Object(); }

          long t2 = System.currentTimeMillis();
          System.out.println("Time:"+(t2-t1) + " o="+o);
          }

          }

          The results:
          1) clean + H1942:
          Time:14734 o=java.lang.Object@205dbce4

          2) clean + H1942 + this JIRA
          Time:13719 o=java.lang.Object@20f2d684

          3) clean + H1942 + this JIRA + helper inlining JIRA (Note: JIT does optimize address ariphmethics today and do not moves fs[14]+offset out of the loops)
          Time:2640 o=java.lang.Object@20488304

          Of course the performance benefit on real application will be 100 times lower.

          Show
          Mikhail Fursov added a comment - Here is a microtest, that shows that there are no performance degradation with this patch: public class Test { public static void main(String[] args) { Test t = new Test(); //resolve and initialize the helper. Needed only for helper inlining. foo2(); } public static void foo2() { long t1 = System.currentTimeMillis(); Object o = null; for (int i=0;i<400*1000*1000;i++) { o = new Object(); } long t2 = System.currentTimeMillis(); System.out.println("Time:"+(t2-t1) + " o="+o); } } The results: 1) clean + H1942: Time:14734 o=java.lang.Object@205dbce4 2) clean + H1942 + this JIRA Time:13719 o=java.lang.Object@20f2d684 3) clean + H1942 + this JIRA + helper inlining JIRA (Note: JIT does optimize address ariphmethics today and do not moves fs [14] +offset out of the loops) Time:2640 o=java.lang.Object@20488304 Of course the performance benefit on real application will be 100 times lower.
          Hide
          Mikhail Fursov added a comment -

          You are right. the offsets I use here have different meaning. I will update the patch.

          Show
          Mikhail Fursov added a comment - You are right. the offsets I use here have different meaning. I will update the patch.
          Hide
          Ivan Volosyuk added a comment -

          Does frontier allocation still works? Why don't we disable it with 'return false' otherwise?

          Boolean gc_supports_frontier_allocation(unsigned *offset_of_current, unsigned *offset_of_limit) {
          // Need additional support for object offset in native stubs.

          • *offset_of_current = field_offset(GC_Thread_Info, tls_current_free);
          • *offset_of_limit = field_offset(GC_Thread_Info, tls_current_cleaned);
            + *offset_of_current = tls_offset_current;
            + *offset_of_limit = tls_offset_clean;
            return true;
            ^^^ here
          Show
          Ivan Volosyuk added a comment - Does frontier allocation still works? Why don't we disable it with 'return false' otherwise? Boolean gc_supports_frontier_allocation(unsigned *offset_of_current, unsigned *offset_of_limit) { // Need additional support for object offset in native stubs. *offset_of_current = field_offset(GC_Thread_Info, tls_current_free); *offset_of_limit = field_offset(GC_Thread_Info, tls_current_cleaned); + *offset_of_current = tls_offset_current; + *offset_of_limit = tls_offset_clean; return true; ^^^ here
          Hide
          Mikhail Fursov added a comment -

          Weldon,
          this patch does not break the old design. So GCv4 and GCv5 will continue work as they are.

          Show
          Mikhail Fursov added a comment - Weldon, this patch does not break the old design. So GCv4 and GCv5 will continue work as they are.
          Hide
          weldon washburn added a comment -

          There are two outstanding issues:

          1)
          We need to get consensus on Xiao Feng's comments on API design

          2)
          A patch for GCV5 will need to be added to this JIRA. There needs to be one commit for all GCs.

          Show
          weldon washburn added a comment - There are two outstanding issues: 1) We need to get consensus on Xiao Feng's comments on API design 2) A patch for GCV5 will need to be added to this JIRA. There needs to be one commit for all GCs.
          Hide
          Mikhail Fursov added a comment -

          The patch must be applied inside of gc_cc folder after the patch from H1942.

          Show
          Mikhail Fursov added a comment - The patch must be applied inside of gc_cc folder after the patch from H1942.
          Hide
          Mikhail Fursov added a comment -

          the patch

          Show
          Mikhail Fursov added a comment - the patch

            People

            • Assignee:
              weldon washburn
              Reporter:
              Mikhail Fursov
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development