And delete the generic icon member which has been dormant since
switching to FileIconProvider. Fixes icon column not being properly
painted as icon cells.
As it turns out, Dr. POSIX doesn't require that post-mmap() changes
to a file are reflected in the memory mappings. So we don't actually
have to care about the file size changing (or the contents.)
IIUC, as long as all the MAP_SHARED mappings that refer to the same
inode are in sync, we're good.
This means that VMObjects don't need resizing capabilities. I'm sure
there are ways we can take advantage of this fact.
Add Bitmap::view() and forward most of the calls to BitmapView since
the code was identical.
Bitmap is now primarily concerned with its dynamically allocated
backing store and BitmapView deals with the rest.
AK::Bitmap is an awkwardly modal class which can either own or wrap
the underlying data. To get ourselves out of this unpleasant situation,
this patch adds BitmapView to replace the wrapped mode.
A BitmapView is simply a { data pointer, bit count } tuple internally
and provides all the convenient functionality of a bitmap class.
This makes them available for use by other language servers.
Also as a bonus, update the Shell language server to discover some
symbols and add go-to-definition functionality :^)
Mostly due to the fact that clang-format allows aligned comments via
AlignTrailingComments.
We could also use raw string literals in inline asm, which clang-format
deals with properly (and would be nicer in a lot of places).
Instead of keeping AnonymousVMObject::m_cow_map in an OwnPtr<Bitmap>,
just make the Bitmap a regular value member. This increases the size
of the VMObject by 8 bytes, but removes some of the kmalloc/kfree spam
incurred by sys$fork().
This commit removes the only 3rd party library (and its usages)
in serenity: puff, which is used for deflate decompression. and
replaces it with the existing original serenity implementation
in LibCompress. :^)
This is a little bit messy, but basically if an ELF object is non-PIE,
we have to account for the executable mapping being at a hard-coded
offset and subtract that when doing symbolication.
There's probably a nicer way to solve this, I just hacked this together
so we can see "cc1plus" and friends in profiles. :^)
The QEMU's `--accel hvf` command was recently enabled in the `run.sh`
script, but it sadly doesn't work on macOS Big Sur: you need to first
sign your code by adding an `entitlements.xml` file and running a
simple command.
Since we know for sure that the virtual memory regions in the new
process being created are not being used on any CPU, there's no need
to do TLB flushes for every mapped page.
In multi-process profiles, the same ELF objects tend to occur many
times (everyone has libc.so for example) so we will quickly run out
of VM if we map each object once per process that uses it.
Fix this by adding a "mapped object cache" that maps the path of
an ELF object to a cached memory mapping and wrapping ELF::Image.
Extracted a method from the code in the File Manager application which
added actions for activating launch handlers found for the selected
file from the context menu. Applied this method to desktop files
and shortcuts.
Note: made some launch handler related methods in the DirectoryView
static or const which allows passing const DirectoryView& to certain
methods.
Dynamic Vector allocations in sys$select() were showing up in the
full-system profile and since there will never be more than FD_SETSIZE
file descriptors to worry about, we can confidently add enough inline
capacity to this Vector that it never has to kmalloc.
To compensate for the increased stack usage, reduce the size of the
FDInfo struct while we're here. :^)
