Opened 12 years ago

Closed 12 years ago

Last modified 10 years ago

#2105 closed bug (invalid)

garbage collection confusing in ghci for foreign objects

Reported by: Frederik Owned by:
Priority: normal Milestone:
Component: GHCi Version: 6.8.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Hello, I am not sure if this is a bug or just a question. I have a linear algebra library which is allocating vectors etc. on the heap, I think mostly with newForeignPtr. When I use my library in ghci, and turn on debugging, it becomes clear that vectors I create are being garbage collected about one second after they are created:

> let v = ...
> v
(prints debugging info as v is computed)
(prints representation of v)
> (one second later, prints a debugging message 
indicating that v has been freed)

Thus, the fact that ghci still has a symbol called 'v' is not enough to keep its data from being GC'ed, it seems. Is this a feature? If I create a string from the same data, then the string is not GC'ed:

> let v = ...
> let vstr = show v
> vstr
(prints debugging info as v is computed)
(prints quoted representation of v)
> (one second later, prints debug message 
indicating that v has been freed)
> vstr
(prints quoted representation of v as above, 
but no computation / no debugging messages,
indicating that 'vstr' data was not GC'ed)

I can provide more background if necessary. In my library, the primary datatypes interfacing to foreign blocks are:

-- Allocated blocks         
-- uses 'newForeignPtr finalizerFree'   
type RAlloc e i = (ForeignPtr CChar, ForeignPtr e)
-- "Raw Sparse Vector"        
data RSV e i = RSV (ForeignPtr (RSV e i)) (RAlloc e i)
                   deriving Typeable               

Change History (5)

comment:1 Changed 12 years ago by simonmar

difficulty: Unknown

I think we'll need more information here. Can you construct a small example of a ForeignPtr that is freed when you expect it to be retained?

Since a ForeignPtr can only be derferenced in the IO monad, is v in your example an IO computation? Or perhaps you're using unsafePerformIO to dereference the ForeignPtr?

comment:2 Changed 12 years ago by Frederik

Resolution: invalid
Status: newclosed

Thanks for the reply, I checked more closely and it turns out that the stuff being freed was just temporarily allocated by the 'show' instance. The thunk for the named variable is only evaluated once and isn't GC'ed. Sorry again!

comment:3 Changed 11 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:4 Changed 11 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:5 Changed 10 years ago by simonmar

Type of failure: Runtime performance bug
Note: See TracTickets for help on using tickets.