This seems to more than fix a performance regression that we
detected on a metadata-allocation microbenchmark.
A few months ago, I improved the metadata cache representation
and changed the metadata allocation scheme to primarily use malloc.
Previously, we'd been using malloc in the concurrent tree data
structure but a per-cache slab allocator for the metadata itself.
At the time, I was concerned about the overhead of per-cache
allocators, since many metadata patterns see only a small number
of instantiations. That's still an important factor, so in the
new scheme we're using a global allocator; but instead of using
malloc for individual allocations, we're using a slab allocator,
which should have better peak, single-thread performance, at the
cost of not easily supporting deallocation. Deallocation is
only used for metadata when there's contention on the cache, and
specifically only when there's contention for the same key, so
leaking a little isn't the worst thing in the world.
The initial slab is a 64K globally-allocated buffer.
Successive slabs are 16K and allocated with malloc.
rdar://28189496
For this we are linking the new re-mangler instead of the old one into the swift runtime library.
Also we are linking the new de-mangling into the swift runtime library.
It also switches to the new mangling for class names of generic swift classes in the metadata.
Note that for non-generic class we still have to use the old mangling, because the ObjC runtime in the OS depends on it (it de-mangles the class names).
But names of generic classes are not handled by the ObjC runtime anyway, so there should be no problem to change the mangling for those.
The reason for this change is that it avoids linking the old re-mangler into the runtime library.
The old method of constructing a mangled class name does not work anymore with the new mangling scheme.
Also, by using the re-mangler, _typeByName now works with class names containing non-ascii characters.
This breaks the build on exherbo, which uses target tripled linker
names. Furthermore, the default name on unix-ish systems for the linker
is `ld`. This can be a symlink to a specific implementation, usually
named as ld.<name> (e.g. `ld.bfd` or `ld.gold`). Use the cmake variable
for the linker rather than hardcoding the name.
This seems to more than fix a performance regression that we
detected on a metadata-allocation microbenchmark.
A few months ago, I improved the metadata cache representation
and changed the metadata allocation scheme to primarily use malloc.
Previously, we'd been using malloc in the concurrent tree data
structure but a per-cache slab allocator for the metadata itself.
At the time, I was concerned about the overhead of per-cache
allocators, since many metadata patterns see only a small number
of instantiations. That's still an important factor, so in the
new scheme we're using a global allocator; but instead of using
malloc for individual allocations, we're using a slab allocator,
which should have better peak, single-thread performance, at the
cost of not easily supporting deallocation. Deallocation is
only used for metadata when there's contention on the cache, and
specifically only when there's contention for the same key, so
leaking a little isn't the worst thing in the world.
The initial slab is a 64K globally-allocated buffer.
Successive slabs are 16K and allocated with malloc.
rdar://28189496
- Create separate swift_begin.o/swift_end.o for lib/swift and
lib/swift_static. The static swift_begin.o does not call
swift_addNewDSOImage() at startup.
- Update ToolChains.cpp to use the correct swift_begin.o/swift_end.o
files for the `-static-stdlib` and `-static-executable` options.
- Rename swift::addNewDSOImage() to swift_addNewDSOImage() and
export using SWIFT_RUNTIME_EXPORT.
- Move ELF specific parts of ImageInspection.h into
ImageInspectionELF.h.
- For ELF targets, keep track of shared objects as they are
dynamically loaded so that section data can be added to
the protocol conformance and type metadata caches after
initialisation (rdar://problem/19045112).
- CYGWIN symbol is used to distinguish Cygwin environment from other OS
and other environment in Windows.
- Added windows and windowsCygnus to OSVersion in StdlibUnittest
