Alien-Judy
view release on metacpan or search on metacpan
src/judy-1.0.5/ltmain.sh view on Meta::CPAN
# Only append if the libtool object file exists.
test -z "$run" && cat >> ${libobj}T <<EOF
# Name of the non-PIC object.
non_pic_object=none
EOF
fi
$run $mv "${libobj}T" "${libobj}"
# Unlock the critical section if it was locked
if test "$need_locks" != no; then
$run $rm "$lockfile"
fi
exit $EXIT_SUCCESS
;;
# libtool link mode
link | relink)
modename="$modename: link"
src/judy-1.0.5/test/malloc-pre2.8a.c view on Meta::CPAN
/*
malloc_trim(size_t pad);
If possible, gives memory back to the system (via negative
arguments to sbrk) if there is unused memory at the `high' end of
the malloc pool. You can call this after freeing large blocks of
memory to potentially reduce the system-level memory requirements
of a program. However, it cannot guarantee to reduce memory. Under
some allocation patterns, some large free blocks of memory will be
locked between two used chunks, so they cannot be given back to
the system.
The `pad' argument to malloc_trim represents the amount of free
trailing space to leave untrimmed. If this argument is zero,
only the minimum amount of memory to maintain internal data
structures will be left (one page or less). Non-zero arguments
can be supplied to maintain enough trailing space to service
future expected allocations without having to re-obtain memory
from the system.
src/judy-1.0.5/test/malloc-pre2.8a.c view on Meta::CPAN
they can be individually obtained and released from the host
system. A request serviced through mmap is never reused by any
other request (at least not directly; the system may just so
happen to remap successive requests to the same locations).
Segregating space in this way has the benefits that:
1. Mmapped space can ALWAYS be individually released back
to the system, which helps keep the system level memory
demands of a long-lived program low.
2. Mapped memory can never become `locked' between
other chunks, as can happen with normally allocated chunks, which
means that even trimming via malloc_trim would not release them.
3. On some systems with "holes" in address spaces, mmap can obtain
memory that sbrk cannot.
However, it has the disadvantages that:
1. The space cannot be reclaimed, consolidated, and then
used to service later requests, as happens with normal chunks.
2. It can lead to more wastage because of mmap page alignment
src/judy-1.0.5/test/malloc-pre2.8a.c view on Meta::CPAN
Malloc only has limited ability to detect failures of MORECORE
to supply contiguous space when it says it can. In particular,
multithreaded programs that do not use locks may result in
rece conditions across calls to MORECORE that result in gaps
that cannot be detected as such, and subsequent corruption.
If you are using this malloc with something other than sbrk (or its
emulation) to supply memory regions, you probably want to set
MORECORE_CONTIGUOUS as false. As an example, here is a custom
allocator kindly contributed for pre-OSX macOS. It uses virtually
but not necessarily physically contiguous non-paged memory (locked
in, present and won't get swapped out). You can use it by
uncommenting this section, adding some #includes, and setting up the
appropriate defines above:
#define MORECORE osMoreCore
#define MORECORE_CONTIGUOUS 0
There is also a shutdown routine that should somehow be called for
cleanup upon program exit.
src/judy-1.0.5/test/malloc-pre2.8a.c view on Meta::CPAN
#ifdef _DEBUG
/* #define TRACE */
#endif
/* Support for USE_MALLOC_LOCK */
#ifdef USE_MALLOC_LOCK
/* Wait for spin lock */
static int slwait (int *sl) {
while (InterlockedCompareExchange ((void **) sl, (void *) 1, (void *) 0) != 0)
Sleep (0);
return 0;
}
/* Release spin lock */
static int slrelease (int *sl) {
InterlockedExchange (sl, 0);
return 0;
}
#ifdef NEEDED
/* Spin lock for emulation code */
static int g_sl;
#endif
#endif /* USE_MALLOC_LOCK */
( run in 1.007 second using v1.01-cache-2.11-cpan-49f99fa48dc )