heap lifetime question

newer
please help me to find errors from...

older
Re: ANN: interval and polynomial...

Galchin, Vasili

7 Aug 2008 7 Aug '08

1:13 a.m.

Hello, What is the lifetime of various heap objects ... e.g. created by allocaBytes, alloca, etc? Regards, Vasili

Attachments:

attachment.html (text/html — 172 bytes)

Show replies by date

Bulat Ziganshin

7 Aug 7 Aug

1:25 a.m.

Hello Vasili, Thursday, August 7, 2008, 9:13:43 AM, you wrote:

...

What is the lifetime of various heap objects ... e.g. created by allocaBytes, alloca, etc?

alloca/allocaBytes just mimicks stack allocation but actually allocates buffer in usual heap. this buffer lives while references to it exists on practice, it's usually gc'ed by next minor GC -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Galchin, Vasili

1:30 a.m.

so Bulat .. You seem to be saying what I suspect ... i.e. if an allocaBytes call is inside a function, when the function is exited then the said heap object is GC'd?? Regards, Vasili On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin wrote:

...

Hello Vasili,

Thursday, August 7, 2008, 9:13:43 AM, you wrote:

...
What is the lifetime of various heap objects ... e.g. created by

allocaBytes, alloca, etc?

alloca/allocaBytes just mimicks stack allocation but actually allocates buffer in usual heap. this buffer lives while references to it exists

on practice, it's usually gc'ed by next minor GC

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Galchin, Vasili

1:33 a.m.

If I am correct, I cannot associate a ForeignPtr with alloca or allocaBytes object via "newForeignPtr" because the alloca/allocaBytes heap object will be GC'd when I leave the function that allocated this object/. I.e. if I have a heap object that I want to live beyond a function invocation, I must be very careful in coding.... Vasili On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili wrote:

...

so Bulat ..

You seem to be saying what I suspect ... i.e. if an allocaBytes call is inside a function, when the function is exited then the said heap object is GC'd??

Regards, Vasili

On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin < bulat.ziganshin@gmail.com> wrote:

...
Hello Vasili,

Thursday, August 7, 2008, 9:13:43 AM, you wrote:

...
What is the lifetime of various heap objects ... e.g. created by

allocaBytes, alloca, etc?

alloca/allocaBytes just mimicks stack allocation but actually allocates buffer in usual heap. this buffer lives while references to it exists

on practice, it's usually gc'ed by next minor GC

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Bulat Ziganshin

1:58 a.m.

New subject: Re[2]: heap lifetime question

Hello Vasili, Thursday, August 7, 2008, 9:33:32 AM, you wrote: oh, it was my mistake. alloca behavior is completely defined by it's generic implementation: allocaBytes :: Int -> (Ptr a -> IO b) -> IO b allocaBytes size = bracket (mallocBytes size) free although GHC implementation is much more efficient btw, why you can't download ghc library sources and read them yourself??

...

If I am correct, I cannot associate a ForeignPtr with alloca or allocaBytes object via "newForeignPtr" because the alloca/allocaBytes heap object will be GC'd when I leave the function that allocated this object/. I.e. if I have a heap object that I want to live beyond a function invocation, I must be very careful in coding....

Vasili

...

On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili wrote:

so Bulat ..

...

You seem to be saying what I suspect ... i.e. if an allocaBytes call is inside a function, when the function is exited then the said heap object is GC'd??

...

Regards, Vasili

...

On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin wrote: Hello Vasili,

...

Thursday, August 7, 2008, 9:13:43 AM, you wrote:

...
What is the lifetime of various heap objects ... e.g. created by allocaBytes, alloca, etc?

alloca/allocaBytes just mimicks stack allocation but actually allocates buffer in usual heap. this buffer lives while references to it exists

on practice, it's usually gc'ed by next minor GC

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

...

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Galchin, Vasili

2:26 a.m.

New subject: Re[2]: heap lifetime question

In which directory are they? Vasili On Thu, Aug 7, 2008 at 12:58 AM, Bulat Ziganshin wrote:

...

Hello Vasili,

Thursday, August 7, 2008, 9:33:32 AM, you wrote:

oh, it was my mistake. alloca behavior is completely defined by it's generic implementation:

allocaBytes :: Int -> (Ptr a -> IO b) -> IO b allocaBytes size = bracket (mallocBytes size) free

although GHC implementation is much more efficient

btw, why you can't download ghc library sources and read them yourself??

...
If I am correct, I cannot associate a ForeignPtr with alloca or allocaBytes object via "newForeignPtr" because the alloca/allocaBytes heap object will be GC'd when I leave the function that allocated this object/. I.e. if I have a heap object that I want to live beyond a function invocation, I must be very careful in coding....

Vasili

...
On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili wrote:

so Bulat ..

...
You seem to be saying what I suspect ... i.e. if an allocaBytes call is inside a function, when the function is exited then the said heap object is GC'd??

...
Regards, Vasili

...
...
On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin wrote: Hello Vasili,

...
Thursday, August 7, 2008, 9:13:43 AM, you wrote:

...
What is the lifetime of various heap objects ... e.g. created by

allocaBytes, alloca, etc?

alloca/allocaBytes just mimicks stack allocation but actually allocates buffer in usual heap. this buffer lives while references to it exists

on practice, it's usually gc'ed by next minor GC

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

...
...
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Galchin, Vasili

2:33 a.m.

New subject: Re[2]: heap lifetime question

ok .. I will take a stab at it ... /ghc-6.8.2/libraries/base/Foreign/Marshal .... I am not so familiar with the ghc run-time model ... V. On Thu, Aug 7, 2008 at 1:26 AM, Galchin, Vasili wrote:

...

In which directory are they?

Vasili

On Thu, Aug 7, 2008 at 12:58 AM, Bulat Ziganshin < bulat.ziganshin@gmail.com> wrote:

...
Hello Vasili,

Thursday, August 7, 2008, 9:33:32 AM, you wrote:

oh, it was my mistake. alloca behavior is completely defined by it's generic implementation:

allocaBytes :: Int -> (Ptr a -> IO b) -> IO b allocaBytes size = bracket (mallocBytes size) free

although GHC implementation is much more efficient

btw, why you can't download ghc library sources and read them yourself??

...
If I am correct, I cannot associate a ForeignPtr with alloca or allocaBytes object via "newForeignPtr" because the alloca/allocaBytes heap object will be GC'd when I leave the function that allocated this object/. I.e. if I have a heap object that I want to live beyond a function invocation, I must be very careful in coding....

Vasili

...
On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili wrote:

so Bulat ..

...
You seem to be saying what I suspect ... i.e. if an allocaBytes call is inside a function, when the function is exited then the said heap object is GC'd??

...
Regards, Vasili

...
...
On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin wrote: Hello Vasili,

...
Thursday, August 7, 2008, 9:13:43 AM, you wrote:

...
What is the lifetime of various heap objects ... e.g. created by

allocaBytes, alloca, etc?

alloca/allocaBytes just mimicks stack allocation but actually allocates buffer in usual heap. this buffer lives while references to it exists

on practice, it's usually gc'ed by next minor GC

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

...
...
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Henning Thielemann

2:36 a.m.

New subject: Re[2]: heap lifetime question

On Thu, 7 Aug 2008, Bulat Ziganshin wrote:

...

Hello Vasili,

Thursday, August 7, 2008, 9:33:32 AM, you wrote:

oh, it was my mistake. alloca behavior is completely defined by it's generic implementation:

allocaBytes :: Int -> (Ptr a -> IO b) -> IO b allocaBytes size = bracket (mallocBytes size) free

although GHC implementation is much more efficient

That is, it is not a good idea to use 'allocaBytes n return' in order to carry a pointer of an allocated piece of memory out of the inner action.

Galchin, Vasili

2:38 a.m.

New subject: Re[2]: heap lifetime question

that is what I thought .. especially after just looking at the implementation for alloca/allocaBytes. For me and others on thie group is there documentation on the ghc run-time model and also the run-time library architecture. Both would help/aid in reading the code and of course educate more people? Regards, Vasili On Thu, Aug 7, 2008 at 1:36 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

On Thu, 7 Aug 2008, Bulat Ziganshin wrote:

...
Hello Vasili,

Thursday, August 7, 2008, 9:33:32 AM, you wrote:

oh, it was my mistake. alloca behavior is completely defined by it's generic implementation:

allocaBytes :: Int -> (Ptr a -> IO b) -> IO b allocaBytes size = bracket (mallocBytes size) free

although GHC implementation is much more efficient

That is, it is not a good idea to use 'allocaBytes n return' in order to carry a pointer of an allocated piece of memory out of the inner action.

Ben Franksen

10 Aug 10 Aug

5:33 p.m.

New subject: Re[2]: heap lifetime question

Galchin, Vasili wrote:

...

that is what I thought .. especially after just looking at the implementation for alloca/allocaBytes. For me and others on thie group is there documentation on the ghc run-time model and also the run-time library architecture. Both would help/aid in reading the code and of course educate more people?

I'd rather use the FFI Addendum (http://www.cse.unsw.edu.au/~chak/haskell/ffi/) as reference than the ghc implementation. Section 5.8 "MarshalAlloc" says alloca :: Storable a => (Ptr a -> IO b) -> IO b Allocate a block of memory of the same size as malloc, but the reference is passed to a computation instead of being returned. When the computation terminates, free the memory area again. The operation is exception-safe; i.e., allocated memory is freed if an exception is thrown in the marshalling computation. allocaBytes :: Int -> (Ptr a -> IO b) -> IO b As alloca, but allocate a memory area of the given size. The same alignment constraint as for mallocBytes holds. Cheers Ben

6129

Age (days ago)

6132

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Ben Franksen
Bulat Ziganshin
Galchin, Vasili
Henning Thielemann