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

Serverside apps:some objects need not get scanned during the entire life of app.



    • gc
    • sparc
    • generic, solaris_7


      On the server side, the use of java for applications like softswitches which require a large amount of Object pooling and have a large number of live objects which live the
      entire life of the application, the garbage collector unnecessarily scans these
      objects and results in large pause times. Would like to get this problem addressed by suggesting the idea of "concrete references", just like there are
      "weak references". concrete references would be objects which live the entire life of the application and do not need to get scanned by the GC. They could reside in an entirely different heap which need not get touched by GC. This heap could be managed by the user. Alternatively, the existing generational framework could be extended such that these long live objects are put on a very senior heap which is not scanned by GC for very very long times, may be that time can be configured by the user. This would improve the application throughput and reduce the huge GC pause times which are totally unacceptable to such applications.

      The idea is not that these concrete reference objects dont get GC's/collected but such that they never get scanned at all knowing that they dont need to be collected during the entire lifecycle of the application.


      ###@###.###. 2001-04-09

      This is from DynamicSoft. Instead of creating a new RFE, I am adding
      the suggestion here.

      - Smalltalk had this concept of Dead Space. Basically, the idea is that
      if we want to do object pooling, we should be able to allocate a dead space
      that is not subject to garbage collection. The idea is that GC does not
      even look at the dead space, so the objects in dead space live as long
      as the JVM is running. Has anybody else asked for something like this?


        Issue Links



              pbk Peter Kessler
              duke J. Duke
              0 Vote for this issue
              2 Start watching this issue