21–25 of 25 posts
This article is way inaccurate. It recommends approaches that were maybe important in 1997. It also breaks the "profile before optimising" rule. Currently the Java GC works splendidly with lots of short-lived, small immutable classes. Using this approach can be far better for performance than worrying about telling the ArrayList constructor how many elements the list will probably have.
This article is way inaccurate. It recommends approaches that were maybe important in 1997. It also breaks the "profile before optimising" rule. Currently the Java GC works splendidly with lots of short-lived, small immutable classes. Using this approach can be far better for performance than worrying about telling the ArrayList constructor how many elements the list will probably have.
Articles like this make me believe that Java should have just gone with a model designed around fibers that each fiber gets a fiber-local heap and objects that survive the death of the heap or are accessed in a multi-fiber way are moved to a global heap. It would solve the problem with "stop the world" GC dynamics and increase concurrent collecting performance while also adding native fibers to the JVM (and thus make…
The DLG collector as used by Caml Light does what you describe. Updating an object in the global heap to point to a thread-local heap can cause unbounded work to be done before that update as the entire pointed-to structure has to be copied into the global heap first. GC designers really hate write barriers (sections of code that are performed before a pointer is updated) that perform unbounded work.