Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8036913

make DeoptimizeALot dependent on number of threads

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P2 P2
    • 9
    • 9
    • hotspot
    • b40

        Essence of issue is that in gc and in other areas we have stress tests that spawn a lot of threads. This results in more deoptimization with -XX:+DeoptimizeALot in the following way: more threads => more calls of runtime methods defined through macroses IRT_ENTRY, IRT_ENTRY_NO_ASYNC, JRT_ENTRY, JRT_ENTRY_NO_ASYNC and JRT_BLOCK => more calls of InterfaceSupport::deoptimizeAll() in ~VMEntryWrapper() destructor => test timeouts. Test determines number of threads based on host properties, so it's not convenient to address issue using DeoptimizeALotInterval. It would be useful if we have a key that would let us set DeoptimizeALotInterval proportional to number of threads.

        Consider making determining DeoptimizeALotInterval depending of threads number to be a default behavior.

              iignatyev Igor Ignatyev (Inactive)
              atimofee Aleksey Timofeev (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: