3 Replies Latest reply on Apr 30, 2008 12:23 AM by 807557

    Scoped memory (again)

      Thanks for the earlier reply which was very helpful.

      I'm trying to use scoped memory as a way of limiting the amount of CPU being burned by gc. Our application has a huge in-memory cache (really just an instance of ConcurrentHashMap), which is read in as the app starts and then never changes. Yet when gc kicks in this giant cache is scanned by the gc and it can take a looooooong time (read minutes) for gc to figure out what the developers knew all along... that there's nothing to be reclaimed. It would be really nice if the gc knew not to bother looking at the collection.

      It sounds like scoped memory might help out here. My concern is the reference to the CHM object. If I have a reference to the root of my CHM in regular heap, then will the garbage collector follow the root into the scope? I guess so since it needs to check the references in the CHM for pointers back to objects that might live in the main heap.

      I guess the question is this: Is there a way I can instantiate the collection such that the garbage collector will completely ignore it and its contents? The CHM object itself and all the objects used as keys and values are contained entirely within the scope. Access from the "outside world" might therefore need to be via some form of serialization, but that would probably be worth the performance penalty if we could recover the CPU lost doing all that gc.
        • 1. Re: Scoped memory (again)
          Sorry I thought I had replied to this days ago but the post never seemed to make it.

          In theory an implementation could use a scheme whereby heap references written into scope-allocated objects were tracked and hence the load on the GC with respect to scanning the scope lessened. But I'm not aware of an implementation that does that. As far as I know, at this time, Sun Java RTS, simply scans the scope for heap references, hence having the data structure in scope would not save anything in that regard.

          Accessing the data structure would also be awkward as you'd have to enter the scope to do so. I'm not sure what kind fo "serialization" you were thinking of.

          David Holmes
          • 2. Re: Scoped memory (again)
            So a real-time thread could be blocked in scoped-mem while the scope is beeing scanned for heap references ?

            Edited by: michee on Apr 29, 2008 5:18 AM
            • 3. Re: Scoped memory (again)
              GC should be able to scan a scope concurrently with the scope being used by other threads. If you're after Java RTS specifics then I'll have to get back to you.

              There has to be some form of GC/scope "synchronization" but the exact nature is implementation specific. NHRTs should not be blocked from using a scope because the GC scans it, but a NHRT may be delayed entry to, or exit from a scope, because the GC is still scanning it.

              David Holmes