Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: DRLVM
    • Labels:
      None

      Description

      It's for better lookup procedures for methods and fileds resolving; moving Class.getMethod to JNI :
      There was just linear search for lookup methods and fileds in DRLVM, so using hash for lookup improves the performance on startup.

        Activity

        Hide
        Alexey Varlamov added a comment -

        I suggest the following steps to proceed with this issue:
        1) Enhance ClassRegistry with findMatchingMethod / findMatchingDeclaredMethod w/o using hash; and keep Java-side cache (i.e. first check the cache then fall back to JNI). BTW, it is possible to add a lookup cache, like Map<Integer, Member> which maps a hash (name, args) to the member thus avoid recurring JNI calls. Hard to say if caching is beneficial, need some real-world statistics...
        2) Check if using hash on native side gives any improvement over linear search. Frankly, I suspect it is negligible and just complicates code.

        Note, some extra care should be taken for matching covariant return types, it is missing in the prototype patch. Namely, specification states:
        "If more than one method with the same parameter types is declared in a class, and one of these methods has a return type that is more specific than any of the others, that method is returned".

        Show
        Alexey Varlamov added a comment - I suggest the following steps to proceed with this issue: 1) Enhance ClassRegistry with findMatchingMethod / findMatchingDeclaredMethod w/o using hash; and keep Java-side cache (i.e. first check the cache then fall back to JNI). BTW, it is possible to add a lookup cache, like Map<Integer, Member> which maps a hash (name, args) to the member thus avoid recurring JNI calls. Hard to say if caching is beneficial, need some real-world statistics... 2) Check if using hash on native side gives any improvement over linear search. Frankly, I suspect it is negligible and just complicates code. Note, some extra care should be taken for matching covariant return types, it is missing in the prototype patch. Namely, specification states: "If more than one method with the same parameter types is declared in a class, and one of these methods has a return type that is more specific than any of the others, that method is returned".
        Pavel Pervov made changes -
        Summary [drlvm][startup][performance] classloading - lookup for methods and fields [drlvm][startup][performance][classloader] lookup for methods and fields
        Hide
        Vladimir Beliaev added a comment -

        I would change the prefix of this JIRA to [drlvm][kernel] to simplify its tracking since it relates to DRLVM Kernel Classes implementation.

        Show
        Vladimir Beliaev added a comment - I would change the prefix of this JIRA to [drlvm] [kernel] to simplify its tracking since it relates to DRLVM Kernel Classes implementation.
        Hide
        Naumova Natalya added a comment -

        Sorry for delay:
        0) I've made some measurements on large graphic application with AWT/SWING usage, the performance was measured by time from start till end with jemmy library usage and simple "/usr/bin/time" commandline.
        1) this gave ~5% boost on EIOffice startup
        2) yes, Class.getMethod was on the top of the hot methods when Eclipse.TPTP analisys was done.
        3) ofcourse we can do hashing in java code, but it's more convinient and faster when all the searches are done in the same place, I mean all the lookups are leading to the Class.lookup_method(..);

        Show
        Naumova Natalya added a comment - Sorry for delay: 0) I've made some measurements on large graphic application with AWT/SWING usage, the performance was measured by time from start till end with jemmy library usage and simple "/usr/bin/time" commandline. 1) this gave ~5% boost on EIOffice startup 2) yes, Class.getMethod was on the top of the hot methods when Eclipse.TPTP analisys was done. 3) ofcourse we can do hashing in java code, but it's more convinient and faster when all the searches are done in the same place, I mean all the lookups are leading to the Class.lookup_method(..);
        Naumova Natalya made changes -
        Component/s DRLVM [ 12311272 ]
        Hide
        Alexey Varlamov added a comment -

        Natalya, could you please expand on the following topics:
        0) which application or workload you are trying to optimize, how do you measure the startup performance?
        1) do you have any estimations or experimental data on this improvement?
        2) Do you have some profiling data pointing to this bottleneck or it is a wild guess?
        3) Are there many classes with such a big number of members to benefit from hashing vs linear search? I'd expect such issue affecting overall VM execution far more than just reflection. What if we add hashing in reflection Java classes directly?
        4) From my POV the main benefit from the suggested patch (if any) might be caused by shorter path-lenght for obtaining some sole member of a class, i.e. one skips creating an array of all declared methods of the kind (methods/fields etc) for the 1st request. But how does it affect a long run of reflection-intensive apps ?

        Show
        Alexey Varlamov added a comment - Natalya, could you please expand on the following topics: 0) which application or workload you are trying to optimize, how do you measure the startup performance? 1) do you have any estimations or experimental data on this improvement? 2) Do you have some profiling data pointing to this bottleneck or it is a wild guess? 3) Are there many classes with such a big number of members to benefit from hashing vs linear search? I'd expect such issue affecting overall VM execution far more than just reflection. What if we add hashing in reflection Java classes directly? 4) From my POV the main benefit from the suggested patch (if any) might be caused by shorter path-lenght for obtaining some sole member of a class, i.e. one skips creating an array of all declared methods of the kind (methods/fields etc) for the 1st request. But how does it affect a long run of reflection-intensive apps ?
        Naumova Natalya made changes -
        Summary classloading - lookup for methods and fields [drlvm][startup][performance] classloading - lookup for methods and fields
        Naumova Natalya made changes -
        Field Original Value New Value
        Summary uncompressed jar files classloading - lookup for methods and fields
        Description It's for better lookup procedures for methods and fileds resolving; moving Class.getMethod to JNI :
        There was just linear search for lookup methods and fileds in DRLVM, so using hash for lookup improves the performance on startup.
        Naumova Natalya created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Naumova Natalya
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development