5 ms·

That shouldn't usually require any explicit support from the runtime; it can exist as library code (and does - for instance Apache Commons: http://commons.apach

That shouldn't usually require any explicit support from the runtime; it can exist as library code (and does - for instance Apache Commons: http://commons.apache.org/proper/commons-pool/ http://commons.apache.org/proper/commons-pool/ ).

stcredzero 13y ago
> That shouldn't usually require any explicit support from the runtime; it can exist as library code Well, of course. People writing their own logically implies that such can exist as library code. But if you build in support from the runtime, then it might be possible to squeeze out a bit more performance. For example, perhaps it's possible to tell the GC that certain objects don't have to be considered as roots. (And to the extent that this is possible with current libraries, it's because there is support built into the runtime.) EDIT: Also, having these mechanisms as library code probably opens up more opportunities for introducing implementation errors.
- jamesaguilar 13y ago
  Generic buffer caching support looks an awful lot like generational GC. It's faster when you hand-roll it because you know how you're going to use the buffers and which buffers are going to be reused.
  - stcredzero 13y ago
    I'm proposing something that's not quite as foolproof and automatic as generational GC, but more optimal and a lot quicker and safer than hand-rolling. Also something for which profiling is enough to "know how you're going to use the buffers and which buffers are going to be reused." So basically, take something that's a programming problem and reduce it to "profile, then throw some switches."
    - jamesaguilar 13y ago
      I guess I'm just not seeing how that's going to result in anything different than a userspace freelist library.
      - stcredzero 13y ago
        If you do everything correctly, not too much. But you can't assume the former. Also, having the thing baked into the language/runtime will encourage use. It's along the lines of what happens with refactoring facilities that aren't part of the browser/editor/ide. They stay "that esoteric thing over there" and don't get used that much.

stcredzero 13y ago

> That shouldn't usually require any explicit support from the runtime; it can exist as library code Well, of course. People writing their own logically implies that such can exist as library code. But if you build in support from the runtime, then it might be possible to squeeze out a bit more performance. For example, perhaps it's possible to tell the GC that certain objects don't have to be considered as roots. (And to the extent that this is possible with current libraries, it's because there is support built into the runtime.) EDIT: Also, having these mechanisms as library code probably opens up more opportunities for introducing implementation errors.

jamesaguilar 13y ago
Generic buffer caching support looks an awful lot like generational GC. It's faster when you hand-roll it because you know how you're going to use the buffers and which buffers are going to be reused.
- stcredzero 13y ago
  I'm proposing something that's not quite as foolproof and automatic as generational GC, but more optimal and a lot quicker and safer than hand-rolling. Also something for which profiling is enough to "know how you're going to use the buffers and which buffers are going to be reused." So basically, take something that's a programming problem and reduce it to "profile, then throw some switches."
  - jamesaguilar 13y ago
    I guess I'm just not seeing how that's going to result in anything different than a userspace freelist library.
    - stcredzero 13y ago
      If you do everything correctly, not too much. But you can't assume the former. Also, having the thing baked into the language/runtime will encourage use. It's along the lines of what happens with refactoring facilities that aren't part of the browser/editor/ide. They stay "that esoteric thing over there" and don't get used that much.