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

FileInput/OutputStream cleanup should be improved

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: tbd_major
    • Component/s: core-libs
    • Labels:
      None

      Description

      FileInputStream relies on finalization to perform final closes if the FIS is not already closed.
      This results in extra work for GC that occurs in a burst. The cleanup of FileInputStreams
      should happen sooner and not contribute to overhead in GC.
      With PhantomReferences a lightweight cleanup mechanism or other suitable mechanism could be implemented.

        Issue Links

          Activity

          Hide
          alanb Alan Bateman added a comment -

          The issue can be easily worked around by using Files.newInputStream instead.
          Show
          alanb Alan Bateman added a comment - The issue can be easily worked around by using Files.newInputStream instead.
          Hide
          kbarrett Kim Barrett added a comment -
          JDK-8071507 would improve a PhantomReference-based solution in those cases where the application failed to explicitly close the stream.
          Show
          kbarrett Kim Barrett added a comment - JDK-8071507 would improve a PhantomReference-based solution in those cases where the application failed to explicitly close the stream.
          Hide
          mchung Mandy Chung added a comment -
          I agree that we should move away from finalizer and use PhantomReference.
          Show
          mchung Mandy Chung added a comment - I agree that we should move away from finalizer and use PhantomReference.
          Hide
          rriggs Roger Riggs added a comment -
          The unresolvable compatibility issue is the requirement in FileInputStream and FileOutputStream finalizer methodss to call close.
          The proposed reference based cleaners can not implement anything calling close() because it would require holding a reference to the FIS/FOS which would prevent the stream from becoming phantom referenced.

          Since it is unknown/unknowable how many FIS/FOS subclasses might rely on overriding close or finalize the compatibility issue is severe. Only a long term (multiple release) restriction to deprecate or invalidate overriding would have possibility of eventually eliminating the compatibility problem.
          Show
          rriggs Roger Riggs added a comment - The unresolvable compatibility issue is the requirement in FileInputStream and FileOutputStream finalizer methodss to call close. The proposed reference based cleaners can not implement anything calling close() because it would require holding a reference to the FIS/FOS which would prevent the stream from becoming phantom referenced. Since it is unknown/unknowable how many FIS/FOS subclasses might rely on overriding close or finalize the compatibility issue is severe. Only a long term (multiple release) restriction to deprecate or invalidate overriding would have possibility of eventually eliminating the compatibility problem.

            People

            • Assignee:
              rriggs Roger Riggs
              Reporter:
              rriggs Roger Riggs
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated: