#14059: Fix refcount/deallocation of integers
-----------------------------+----------------------------------------------
Reporter: SimonKing | Owner: rlm
Type: defect | Status: new
Priority: blocker | Milestone: sage-5.7
Component: memleak | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
-----------------------------+----------------------------------------------
Comment (by jpflori):
I think the point of this black magic is to keep a pool of pointers to
Sage integers rather than allocating/freeing one each time a new one is
needed/deleted.
So when you want a new integer and there are preallocated ones left you
just grab one and when you want to delete one, and there is room left in
the pool, you put it back there.
FLINT more or less uses a similar strategy (in single threaded mode).
The commented out line makes sense, inside the memory allocated for a Sage
integer, we move to the address reserved for the mpz structure and
initialize it, I guess its just illegal to cast to mpz_t type which is a
typedef for an array of mpz of size one, something like mpz* should be
used.
Not quite sure what the global dummy integer is used for, obviously for
dark magic refcounting, but still unclear to me.
The point of the global dummy integer is to fool.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14059#comment:12>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
