# Stack-allocating wrapped C++ objects
**URL:** https://discourse.julialang.org/t/stack-allocating-wrapped-c-objects/2635
**Category:** General Usage
**Created:** [March 13, 2017, 8:55am UTC](https://discourse.julialang.org/t/stack-allocating-wrapped-c-objects/2635 "2017-03-13T08:55:00Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@barche](https://discourse.julialang.org/u/barche)
#### Post date: [March 13, 2017, 8:55am UTC](https://discourse.julialang.org/t/stack-allocating-wrapped-c-objects/2635/1 "2017-03-13T08:55:00Z")
In CxxWrap.jl, each C++ type has an associated type of the form:
```julia
type WrappedCxxType
ptr::Ptr{Void} # Pointer to the C++ object
end
```
The reason for this is that the C++ object may be created using a constructor called from Julia, so it needs a finalizer associated with it. Unfortunately, this also means the wrapper is heap-allocated, even when it is returned for an already existing object and no finalizer is needed. So for performance reasons, I really want to make this an immutable, but then I see no way to delete an allocated object when needed (apart from manually calling a function). The performance problem comes up running a sparse matrix assembly loop for example, where the Julia loop is twice as slow as the C++ loop because of these allocations.
To alleviate this, I was thinking of the following construct:
```julia
# Used as the constructor return type
type AllocatedWrappedCxxType
ptr::Ptr{Void} # Pointer to the C++ object
end
# Used as existing pointer and reference return type
immutable WrappedCxxTypeRef
ptr::Ptr{Void} # Pointer to the C++ object
end
```
In addition to that, there would be a `convert` function to convert between both types and function signatures would take the union of these types as arguments. I’m hesitating to implement this, because it feels a bit complicated and I want to make sure I’m not missing a more obvious solution.
Also, what’s the progress on this:
[https://github.com/JuliaLang/julia/pull/12205](https://github.com/JuliaLang/julia/pull/12205)
Seems like it would be the perfect solution here.
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [March 13, 2017, 11:31am UTC](https://discourse.julialang.org/t/stack-allocating-wrapped-c-objects/2635/2 "2017-03-13T11:31:39Z")
You can certainly do this. It’ll just segfault if you don’t manage memory correctly since it won’t do that automatically anymore.
The stack allocation PR won’t handle this case.
---
### Author:  [@Michael\_Eastwood](https://discourse.julialang.org/u/Michael_Eastwood)
#### Post date: [March 13, 2017, 6:05pm UTC](https://discourse.julialang.org/t/stack-allocating-wrapped-c-objects/2635/3 "2017-03-13T18:05:51Z")
This is somewhat off-topic, but I don’t think you can reasonably rely on the finalizer to delete the object. In my experience these objects tend to live in memory for a lot longer than you expect because the Julia GC doesn’t know how large they are.
Therefore I think you should prefer manually managing the memory or avoiding using `Ptr{Void}` as a field type. In my case I was able to do the latter, but I think I pay for it by doing extra copies when moving data between Julia and C++.
See for reference
> [@\[Solved\] Debugging an apparent memory leak](https://discourse.julialang.org/t/solved-debugging-an-apparent-memory-leak/1828/2):
>
> Updating this thread now that I’ve figured out what the problem was. Hopefully this helps somebody coming from Google (hi!). The problem is not at all related to the code structure I outlined in the previous post, but rather the details of the long\_computation function are at fault. Essentially I wrote a wrapper around a C++ library that does things like type MyCxxType ptr :: Ptr{Void} end function MyCxxType() ptr = ccall( ... ) # new CxxType() output = MyCxxType(ptr) finaliz…
>
>
> After reading \[this post\](https://groups.google.com/forum/#!topic/julia-users/4a…SWQTJPFKc) on the mailing list I started bisecting and found that after https://github.com/JuliaLang/julia/commit/2ecb6d5c58e8 the function \`cholfact\` does no longer free its memory after use. It is a quite big commit but my guess is that some "finalizer command" is not sent to cholmod for it to release its internal memory.
>
> The test script I used is the same one as in the mailing list:
>
> \`\`\` julia
> function f(n)
> A = speye(n)
> fact = cholfact(A)
> for i=1:1000
> fact = cholfact(A)
> end
> end
> \`\`\`
>
> The memory allocations are not seen by \`@time\` so some external program like \`htop\` can be used. This is the status after running the test script a couple of times for \`n = 10\_000\`:
>
> !\[screenshot from 2015-06-13 04 25 59\](https://cloud.githubusercontent.com/assets/1282691/8142661/52f5a70c-1184-11e5-88d6-d7e9ccaccaf6.png)
>
> The memory is not reclaimed until Julia is exited.
>
> CC @andreasnoack