History log of /openbsd-src/lib/libc/stdlib/malloc.c (Results 26 – 50 of 297)
Revision Date Author Comments
# 5576bc40 19-Sep-2021 tb <tb@openbsd.org>

Switch two calls from memset() to explicit_bzero()

This matches the documented behavior more obviously and ensures that
these aren't optimized away, although this is unlikely.

Discussed with deraad

Switch two calls from memset() to explicit_bzero()

This matches the documented behavior more obviously and ensures that
these aren't optimized away, although this is unlikely.

Discussed with deraadt and otto

show more ...


# 205367eb 23-Jul-2021 otto <otto@openbsd.org>

Make MALLOC_STATS compile again; noted by Omar Polo and Joe Nelson


# 293988a7 09-Apr-2021 otto <otto@openbsd.org>

An extra internal consistency check and a missing stats adjustment. ok tb@


# c9c2a8bc 09-Mar-2021 otto <otto@openbsd.org>

Change the implementation of the malloc cache to keep lists of
regions of a given size. In snaps for a while, committing since
no issues were reported and a wider audience is good. ok deraadt@


# 19aed9fc 25-Feb-2021 otto <otto@openbsd.org>

- Make use of the fact that we know how the chunks are aligned, and
write 8 bytes at the time by using a uint64_t pointer. For an
allocation a max of 4 such uint64_t's are written spread over the
all

- Make use of the fact that we know how the chunks are aligned, and
write 8 bytes at the time by using a uint64_t pointer. For an
allocation a max of 4 such uint64_t's are written spread over the
allocation. For pages sized and larger, the first page is junked in
such a way.
- Delayed free of a small chunk checks the corresponiding way.
- Pages ending up in the cache are validated upon unmapping or re-use.
In snaps for a while

show more ...


# 3e142b5f 23-Nov-2020 otto <otto@openbsd.org>

mapalign() only handles allocations >= a page; problem found by and ok semarie@


# 87afc19e 12-Oct-2020 deraadt <deraadt@openbsd.org>

make fixed-sized fixed-value mib[] arrays be const
ok guenther tb millert


# 8d0b0dbd 09-Oct-2020 otto <otto@openbsd.org>

As noted by tb@ previous commit only removed an unused fucntion.
So redo previous commit properly:
Use random value for canary bytes; ok tb@.


# 321ee9bb 06-Oct-2020 otto <otto@openbsd.org>

Use random value for canary bytes; ok tb@


# ee0eab5e 06-Sep-2020 otto <otto@openbsd.org>

For page-sized and larger allocations do not put the pages we're
shaving off into the cache but unamp them. Pages in the cache get
re-used and then a future grow of the first allocation will be
hampe

For page-sized and larger allocations do not put the pages we're
shaving off into the cache but unamp them. Pages in the cache get
re-used and then a future grow of the first allocation will be
hampered. Also make realloc a no-op for small shrinkage.
ok deraadt@

show more ...


# df69c215 28-Jun-2019 deraadt <deraadt@openbsd.org>

When system calls indicate an error they return -1, not some arbitrary
value < 0. errno is only updated in this case. Change all (most?)
callers of syscalls to follow this better, and let's see if

When system calls indicate an error they return -1, not some arbitrary
value < 0. errno is only updated in this case. Change all (most?)
callers of syscalls to follow this better, and let's see if this strictness
helps us in the future.

show more ...


# fbc4bd4f 23-May-2019 otto <otto@openbsd.org>

Only override size of chunk if we're not given the actual length.
Fixes malloc_conceal...freezero with malloc options C and/or G.


# e03a3151 10-May-2019 otto <otto@openbsd.org>

Inroduce malloc_conceal() and calloc_conceal(). Similar to their
counterparts but return memory in pages marked MAP_CONCEAL and on
free() freezero() is actually called.


# e02928f1 10-Jan-2019 otto <otto@openbsd.org>

Move default numer of pools in the multi-threaded case to 8. Various tests
by me and others indicate that it is the optimum.


# fa2b6411 10-Jan-2019 otto <otto@openbsd.org>

Make the "not my pool" searching loop a tiny bit smarter, while
making the number of pools variable. Do not document the malloc
conf settings atm, don't know yet if they will stay. Thanks to all
th

Make the "not my pool" searching loop a tiny bit smarter, while
making the number of pools variable. Do not document the malloc
conf settings atm, don't know yet if they will stay. Thanks to all
the testers. ok deraadt@

show more ...


# af4645ac 10-Dec-2018 otto <otto@openbsd.org>

Improve speed for the multi-threaded case by reducing lock contention.
tested by many; ok florian@


# e23a8110 09-Dec-2018 florian <florian@openbsd.org>

style; OK otto


# 23998629 27-Nov-2018 otto <otto@openbsd.org>

Refactor "find the right pool" code into a function. ok djm@ tb@


# acb3f83f 21-Nov-2018 otto <otto@openbsd.org>

Introducing malloc_usable_size() was a mistake. While some other
libs have it, it is a function that is considered harmful, so:

Delete malloc_usable_size(). It is a function that blurs the line
betw

Introducing malloc_usable_size() was a mistake. While some other
libs have it, it is a function that is considered harmful, so:

Delete malloc_usable_size(). It is a function that blurs the line
between malloc managed memory and application managed memory and
exposes some of the internal workings of malloc. If an application
relies on that, it is likely to break using another implementation
of malloc. If you want usable size x, just allocate x bytes. ok
deraadt@ and other devs

show more ...


# 72ca0bda 19-Nov-2018 guenther <guenther@openbsd.org>

Fix compilation on alpha, where DEF_WEAK() really must be paired with
PROTO_NORMAL(). Problem noted by deraadt@


# f5c5425b 18-Nov-2018 otto <otto@openbsd.org>

Implement malloc_usable_size(); ok millert@ deraadt@ and jmc@ for the man page


# 031d6358 06-Nov-2018 otto <otto@openbsd.org>

Use the new vm.malloc_conf sysctl; ok millert@ deraadt@


# 7a9442eb 05-Nov-2018 otto <otto@openbsd.org>

Implement C11's aligned_alloc(3). ok guenther@


# 68bf6e46 07-Apr-2018 otto <otto@openbsd.org>

sys/uio.h is not used anymore


# 64679b8a 30-Mar-2018 otto <otto@openbsd.org>

fix MALLOC_STATS; spotted by and ok semarie@


12345678910>>...12