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

Logic for attaching/detaching native threads could be improved

    XMLWordPrintable

    Details

    • Subcomponent:
    • Understanding:
      Cause Known

      Description

      Currently, we attach a native thread to VM before we jump into upcall code, and we later detach when we're done with the upcall.

      In cases where the native library creates a thread pool, and keeps hitting upcalls with the same few threads, this scheme puts the VM under an enormous amount of pressure, as these threads are not recognized by the JVM, which will create a new Thread object each time (even though the underlying native thread is the same).

      For instance, when experimenting with a Panama-based port of the Fuse library:

      https://github.com/skymatic/fuse-panama

      We noted that the VM was generating ~450G of memory in j.l.Thread instances which was obviously having a negative impact in terms of performance.

      JNR does not suffer from this issue. JNR seem to feature an heuristics so that after a given thread has been attached enough times (1000) it is no longer detached. This works in the long run, although it does create a fair amount of garbage at the beginning of the application lifecycle.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mcimadamore Maurizio Cimadamore
              Reporter:
              mcimadamore Maurizio Cimadamore
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: