I'm not sure what would lead you to have abundant enough unboxed MVar's to
make a difference with GC. I'm happy to be wrong, but I think most
situations where you want an MVar you want the indirection. If you don't
want the indirection you probably don't want some feature of MVar and
should use
Ryan: would an unboxed value Mvar, Eg to write StrictMvar (), avoid
creating extra gc pressure / traversal a?
On Thu, Oct 15, 2020 at 4:23 PM Ryan Yates wrote:
> Ah yes. In my research work I extended Mutable Constructor fields to
> allow a mutable array field to help with that problem. This
Ah yes. In my research work I extended Mutable Constructor fields to allow
a mutable array field to help with that problem. This allowed me to have a
Nil constructor in a sum type and a Node constructor with normal fields as
well as an array of mutable fields. Pointer tagging worked as expected
This might be lost in the noise for MVar and TVar, but for arrays, there
are tremendous advantages to cutting out the extra heap objects.
On Thu, Oct 15, 2020, 1:10 PM Ryan Yates wrote:
> I haven't been following this discussion too closely, but in my research
> work I found that some of the
I haven't been following this discussion too closely, but in my research
work I found that some of the benefits that I wanted in this direction were
already there with pointer tagging.
On Thu, Oct 15, 2020 at 12:59 PM David Feuer wrote:
> Yes, that's something quite different. We'd need a whole
Yes, that's something quite different. We'd need a whole different heap
object type for such MVars and TVars. My approach covers the case where the
unboxed thing can only take on a few values, for some value of "a few"
which, depending on implementation, may or may not be very small. If the
nulls
Indeed, I mean things that aren’t pointery, and could be represented by a
tvar paired with a mutable byte array or mvar with mutable byte array, but
which we’d want considered as a single heap object from the rts/gc
perspective.
On Thu, Oct 15, 2020 at 11:58 AM David Feuer wrote:
> Sorry,
Sorry, unlifted, not unboxed...
On Thu, Oct 15, 2020, 11:57 AM David Feuer wrote:
> Putting unboxed things in TVar, MVar, etc., is part of Andrew Martin's
> accepted BoxedRep proposal.
>
> On Thu, Oct 15, 2020, 11:44 AM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> A related idea
Putting unboxed things in TVar, MVar, etc., is part of Andrew Martin's
accepted BoxedRep proposal.
On Thu, Oct 15, 2020, 11:44 AM Carter Schonwald
wrote:
> A related idea that came up recently and is perhaps simpler ties into this
> via the lens of having unboxed Mvars/tvars (even if it’s
A related idea that came up recently and is perhaps simpler ties into this
via the lens of having unboxed Mvars/tvars (even if it’s restricted to just
things we can embed in a word64#)
This came up in
https://gitlab.haskell.org/ghc/ghc/-/issues/18798#note_307410, where viktor
had millions of
From a implementors perspective my main questions would be:
* How big is the benefit in practice? How many use cases are there?
* How bad are the costs? (Runtime overhead, rts complexity, ...)
The details of how this would be exposed to a user would are important.
But if the costs are too high
11 matches
Mail list logo
