4 ms·

Generics are totally helpless for runtime things. I would be good for the official runtime to be designed in a plugin way, so that third parties may experiment

by tapirl 4y ago

Generics are totally helpless for runtime things. I would be good for the official runtime to be designed in a plugin way, so that third parties may experiment their own implementations of some aspects of the runtime.

philosopher1234 4y ago
Why can’t they just fork the runtime to experiment?
hsn915 4y ago
func Allocate[T](arena *Arena) *T { var bytes = arena.Bump(sizeof(T), alignof(T)) return (*T) bytes } Any reason why this would not work? Maybe you need to cast to unsafe.Pointer or something before returning, but in theory this _should_ work.
- morelisp 4y ago
  It could probably be made to work, but would it reduce any GC work compared to any other kind of object pool? The returned value will still be accessible from some stack root and need to be scanned, I think regardless of whether the arena was already scanned - the arena would mark the span of the T itself, but any subfields with pointers would need to be scanned from the T as it would need the type information. And if T has no pointer subfields it would not be scanned anyway. So maybe best case you save a mark per T? The advantage of a bump allocator is being able to throw it all out at once at the end and never have to check it while "in use", and I don't think Go's GC would let you do that.
  - hsn915 4y ago
    Right, the pointers would still be scanned by the GC, so we can't elliminate the cost of the GC, unless we completely turn it off (I think that is possible). But the point of the arena allocator is to make allocations and deallocatins very fast. Say you want to allocate many small objects for a very short amount of time and then get rid of all of them. Doing it on an Arena would save a lot of computation that would be required in a typical heap allocator.
    - morelisp 4y ago
      > But the point of the arena allocator is to make allocations and deallocatins very fast... Doing it on an Arena would save a lot of computation that would be required in a typical heap allocator. Relative to a completely naive allocator yes, but relative to any other kind of pooling (e.g. Go's internal small object pools, or a `sync.Pool`, or just a `make([]T, 1000)`) the advantage of a bump allocator is marginal without the ability to avoid the mark overhead and actually throw it all out at once.

by tapirl 4y ago

philosopher1234 4y ago

Why can’t they just fork the runtime to experiment?

hsn915 4y ago

func Allocate[T](arena *Arena) *T { var bytes = arena.Bump(sizeof(T), alignof(T)) return (*T) bytes } Any reason why this would not work? Maybe you need to cast to unsafe.Pointer or something before returning, but in theory this _should_ work.

morelisp 4y ago
It could probably be made to work, but would it reduce any GC work compared to any other kind of object pool? The returned value will still be accessible from some stack root and need to be scanned, I think regardless of whether the arena was already scanned - the arena would mark the span of the T itself, but any subfields with pointers would need to be scanned from the T as it would need the type information. And if T has no pointer subfields it would not be scanned anyway. So maybe best case you save a mark per T? The advantage of a bump allocator is being able to throw it all out at once at the end and never have to check it while "in use", and I don't think Go's GC would let you do that.
- hsn915 4y ago
  Right, the pointers would still be scanned by the GC, so we can't elliminate the cost of the GC, unless we completely turn it off (I think that is possible). But the point of the arena allocator is to make allocations and deallocatins very fast. Say you want to allocate many small objects for a very short amount of time and then get rid of all of them. Doing it on an Arena would save a lot of computation that would be required in a typical heap allocator.
  - morelisp 4y ago
    > But the point of the arena allocator is to make allocations and deallocatins very fast... Doing it on an Arena would save a lot of computation that would be required in a typical heap allocator. Relative to a completely naive allocator yes, but relative to any other kind of pooling (e.g. Go's internal small object pools, or a `sync.Pool`, or just a `make([]T, 1000)`) the advantage of a bump allocator is marginal without the ability to avoid the mark overhead and actually throw it all out at once.