If you're using finalizers to clean up C memory, it's important to know
that the Go garbage collector has no understanding of how much C memory a
given resource holds. This prevents the garbage collector from making smart
decisions about when to release your resources. I've never personally seen
th
On Monday, November 23, 2020 at 6:31:50 AM UTC-5 tokers wrote:
> Are there any documents?
>
https://golang.org/pkg/runtime/#SetFinalizer
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
Finalizers are essential in a highly concurrent system - otherwise you are
doing manual resource management with automatic memory management (a resource)
and its ugly and error prone.
Even though they are no guaranteed to be called they work very well to manage
shared resources.
> On Nov 23,
Are there any documents?
On Monday, November 23, 2020 at 7:28:31 PM UTC+8 Tamás Gulácsi wrote:
> There is a runtime.SetFinalizer, but it is not guaranteed to be run,
> anytime.
> The most idiomatic and safe solution is to have a Close() method on the Go
> side, which frees the C side.
> You may
There is a runtime.SetFinalizer, but it is not guaranteed to be run,
anytime.
The most idiomatic and safe solution is to have a Close() method on the Go
side, which frees the C side.
You may even add a Finalizer that panics if Close haven't been called
before...
tokers a következőt írta (2020.
There is a runtime.SetFinalizer function.
On Sunday, November 22, 2020 at 8:13:22 PM UTC+8 Sean wrote:
> I am writing a Golang wrapper for OpenAL-Soft.
> I need to create some buffers. These operations are happening on the
> OpenAL-Soft side (So C functions). I am loading PCM data into buffers.
On Wed, Aug 22, 2018 at 8:20 AM, 'Florian Uekermann' via golang-nuts
wrote:
> On Tuesday, August 21, 2018 at 7:31:28 AM UTC+2, Keith Randall wrote:
>>
>> There is no conservativeness to unsafe.Pointer. The type information for
>> any object in the heap is recorded at allocation time, and is unrela
On Tuesday, August 21, 2018 at 7:31:28 AM UTC+2, Keith Randall wrote:
>
> There is no conservativeness to unsafe.Pointer. The type information for
> any object in the heap is recorded at allocation time, and is unrelated to
> the type of the reference currently held to it (be it unsafe.Pointer,
There is no conservativeness to unsafe.Pointer. The type information for
any object in the heap is recorded at allocation time, and is unrelated to
the type of the reference currently held to it (be it unsafe.Pointer,
[]byte, *int64, or whatever).
So for 2.2, the answer is no, you are incorrect.
That information is old now - Go has a precise GC now. There is some sort
of metadata stored for each variable related to whether the type contains
pointers (as Jan alluded to earlier in the thread).
On Monday, August 20, 2018 at 7:28:51 AM UTC-7, Florian Uekermann wrote:
>
> From the GC POV, th
>
> From the GC POV, the only interesting thing about an unsafe.Pointer is if
> its value falls anywhere into a GC managed memory block for liveness
> analysis, AFAIK.
>
And then it will check that memory block for stuff that looks like a
pointer (not caring what the actual type being pointed t
On Mon, Aug 20, 2018 at 3:48 PM 'Florian Uekermann' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
>> The garbage collector does not care about the values of items of a []T
when T is not a pointer type nor a type containing transitively any
pointers.
>
> Just to make sure I understand you
>
> The garbage collector does not care about the values of items of a []T
> when T is not a pointer type nor a type containing transitively any
> pointers.
>
Just to make sure I understand you correctly. Are you saying I could hold
an unsafe.Pointer to an array of uint64 and the GC will still
On Mon, Aug 20, 2018 at 2:49 PM 'Florian Uekermann' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> ... which would put unnecessary strain on the GC iirc, because the memory
pointed to would be scanned conservatively (basically assuming everything
in there could be a pointer).
The garbag
Thanks Axel.
Good to know the first part. I have a couple of comments regarding your
answer to the second part.
In regards to your second question: That would require having an array type
> for every possible size, which isn't really tenable.
>
The idea was to use the same array type (`[(^uint
I'm not 100% sure, but… pretty sure? that the GC does not look at the
len/cap fields of slices. Reason being that that would require significant
alias-analysis, as two slices of the same underlying array can have
different lengths and capacities. So treating the underlying array not as
"one object"
Mistake in the second struct. The data field should have the type:
*[(^uint(0)) >> 17]uint64
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr
The garbage collector only runs when your program creates garbage -- the
more your program allocates, the harder the garbage collector will work.
On Thursday, 10 November 2016 15:31:24 UTC+11, vyasgir...@gmail.com wrote:
>
> Is there a way to overwork the garbage collector in go lang?
>
--
You
18 matches
Mail list logo
