It was disabled because hoard2 triggered it far too often.
But now that we're using OpenBSD malloc with different glue,
this isn't an issue anymore.
Closes #18451.
Change-Id: I9a3b1190edbbe0ae3cedfe4df2993441d1f2d629
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8975
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
jam HaikuDepot with nothing to do, best of many runs:
hoard2
real 0m3.519s
user 0m3.348s
sys 0m0.159s
openbsd
real 0m3.481s
user 0m3.327s
sys 0m0.147s
time printf "continue\nsave-report\nquit\nk\n" | Debugger -c Debugger -s 1000
hoard2
real 0m2.295s
user 0m2.505s
sys 0m0.128s
openbsd
real 0m2.896s
user 0m2.809s
sys 0m0.579s
The performance difference in Debugger is due to OpenBSD malloc
actually decommitting memory. If we disable decommit, then
OpenBSD malloc is faster than hoard2 in this case also.
In some particular cases this is a huge speedup. For example, the link
of the "lto-dump" program in GCC seems to hit a pathological case in
hoard2 and our glue code for it; with hoard2 it takes around 23 seconds,
but with this allocator it takes only 2 seconds (!). Overall the
performance difference is much more modest, though.
Overall, system memory usage seems to be up about ~5% (318 MB -> 334 MB
just after boot), and that seems to mostly be due to the allocator
filling its initial caches faster when allocations occur, rather than
lazily allocating.
Change-Id: I071d8f76fbbfa11547bd6da6bf649d111414e780
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8974
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* PagesAllocator: A process-global caching strategy for the allocator.
It deals with allocating virtual addresses and memory, and gives us
back some of the performance that's lost by having an actual
decommitment strategy (which the hoard2 glue code doesn't.)
It uses two SplayTrees to manage free lists, and resizes areas
on allocate if they aren't next to a free chunk (which saves a lot of
time for large reallocations.)
There's still room for improvement here, see inline TODOs. But overall
we get pretty good performance with it.
* Add a TLS slot for the allocator glue to use. Right now it just puts
integers in there (since thread IDs are not evenly distributed),
but we could put a data structure pointer in there as well, potentially.
Change-Id: I56ddb0b022a468dc04275075ed7e174b339c8ca4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8335
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Exactly as-is. Modifications and integration will come in
the next commit.
Change-Id: I685483992d7f593fc46154ddea85a91798044faa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8973
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If we succeed in sending the message on the first try, then we don't
need to allocate anything at all.
This two allocations and a memcpy in the fast path (which is
hit the vast majority of the time, it appears.)
Some methods already did, but used a very large size of 16KB.
Reduce that to 4KB, do it in more places, and use BStackOrHeapArray
where possible.
Change-Id: Ia2d64582e76da6c1850e502107c07cb10bcd8226
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8969
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Rather than allocating a block in the constructor, just wait to
do it until we actually need to add items to the list. This saves
over 200,000 allocations when running "pkgman search" alone.
Change-Id: Ia6a21b963efded2bb4973edc2ba22ff026e01737
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8630
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Handle resizing areas past a reservation, fixing a longstanding TODO.
(The kernel address space implemenation still has the same TODO however.)
* Handle resizing areas past or inside more than one reservation at once.
* When an area shrinks, and it's touching/inside a reservation, expand
the reservation downwards at least to its original size.
Add tests for all these behaviors (they're passing.)
This is now obsolete as the preferred merge strategy is just to
copy the whole directories and then reinstate the __HAIKU__
directives, same as for the FreeBSD network drivers and other
such code.
This is used by some Tracker add-ons including TrackRunner and TrackGit.
Fixes #19386
Change-Id: I329eb9f1f8b2abf2872593d8f4417fa82de0b521
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8911
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Otherwise we'll try to write to some random register at or past the end.
Adjust the bitmasks: rename XHCI_LEGCTLSTS_DISABLE_SMI to RESERVED_BITS
and define it in hex. Also add the "read-only" bits as a separate
declaration, and don't touch those either; then remove the setting
of the "events SMI" bits.
We always did under EFI but not under BIOS. Now, the BIOS loader
reports the root pointer as well, so we don't need to find it again.
Change-Id: Ie83adb53f098d44f2688a1a327c084f94afa2673
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8941
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is necessary when the TEXT section is split.
At this point it may make more sense for libroot to register such
atexit hooks with runtime_loader rather than allocating them itself,
in line with the above comment's suggestion, but that can be investigated
some other time.
Previously this would simply tint the passed in background color.
After hrev58595 this was changed to pass the proper Foreground color instead.
The codepath to disable/enable the color was missed in an oversight,
this puts back the original tint color for the foreground aswell.
Fixes: #19406
Change-Id: I6f75d24316e8ca3ecdb78f11fc8dede88f082780
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8958
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... related to Pose and TextWidget not exactly matching.
Change-Id: Ic9c3f2ecc9a9dc4af4c200bc5a16b9f46d72f9b1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8954
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... by setting the incoming shortcut instead of the old one
in BMenuItem::SetShortcut().
Fixes #19405 a regression hrev58611.
Change-Id: Iecf19a323f6b6ead288e3f1ef1169376b11cddb3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8948
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... by calling Install() on Go() in BPopUpMenu.
Install() prepares item shortcuts and set missing targets to the
target window. Combined with hrev58611 for regular menus this
passes most of the shortcut prep work on to BWindow.
Fixes pop up portion of #19395 a regression from hrev58589.
Change-Id: I8a1615502e0d6e0b75f9cd3ca2a45d08b53d11ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8946
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: John Scipione <jscipione@gmail.com>
If it changed, then don't try to do I/O past the end.
It would presumably just fail anyway, and since the
addition of extra asserts to VMCache page insertion,
will cause assertion failures due to inserting pages
past the end of the cache.
This case is particularly easy to trigger by holding
the down arrow in the keymaps list (i.e. changing keymaps
very rapidly.)
It doesn't make much sense to do this, and the Be Book specifies that
doing so will return an error. A user on the mailing list tested
against BeOS and confirmed that it does reject this, so we should too.
The shortcut detection was working, just not the display of the
modifiers in the menu. I've added back the necessary code to fix
this in BMenuItem.
BWindow does the heavy lifting of preparing the keys and
modifiers. I have changes _FindShortcut() used by BMenuItem to
send the prepared modifiers back to BMenuItem.
Set the parameters raw in the constructor, they will get fixed
up in Install().
I also make sure to use the prepped version of the key and mods
in BWindow::AddShortcut() to remove the old one. This is a minor
update that eliminates an edge failure case of malformed input.
Fixes #19395 a regression from hrev58589.
Change-Id: I4333f89149ff843f92dbffbd53d58ffc2def6760
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8943
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: John Scipione <jscipione@gmail.com>
* Determine whether we're currently dragging by looking at the
current window message what, dragging replaces direct in a few
places especially crucial to drawing semi-transparent dragged
items correctly.
* Export kMsgMouseDragged and kMsgMouseLongDown to the BPoseView
header to check for dragging (but still in BPrivate).
* Turn on outline label drawing for dragged items and remove TODO.
Fixes #6461
Change-Id: I45cd401299dec408b76cb4b9ce1e9350ed59ef5b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8842
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Create a DrawTextWidget() method in BPose to share drawing
between list and icon modes.
* Remove direct param from BPose::DrawIcon() and remove the state
changes from that method.
* Remove direct parameter from TextWidget::Draw(), we can calc it.
* Refactor BPose::Draw() to set the LowColor() only. This is now
considerably more simple to read and understand.
* Refactor ColumnRedraw() to reset colors and drawing mode.
* Many explanatory comments added.
* Remove BackColor() and TextColor(), use LowColor() and HighColor().
* Use AdoptSystemColors() and HasSystemColors() to set colors.
These are virtual in BPoseView and the colros are overridden by
DesktopPoseView, OpenWithPoseView and QueryPoseView.
* Add ReadOnlyTint() version to Utilities that takes a color_which.
* Rename InvertedBackColor() to InvertColorSmart().
* Force Edit name select box background color to be black/or white
depending on the inverse of your background color on Desktop
instead of using document colors.
* Determine if volume is read-only by pose instead of its parent,
this fixes a bug where read-only volumes mounted on a read-write
directory like the Desktop had an editable name even though they
were not supposed to. It wouldn't let you change the name though.
* Remove fIsDesktop param from BPoseView, use only IsDesktopView()
now except in FilePanelPoseView when navigating to the Desktop.
* Update BContainerWindow, DesktopPoseView and FilePanelPoseView
to adjust to this change. IsDesktopView() is always true for
DesktopPoseView, never true otherwise.
* DesktopPoseView disambiguated further from BPoseView. Add a few
virtual override methods.
* Custom Brightness() value on DesktopPoseView based on the default
Desktop color.
* Respond to B_WORKSPACE_ACTIVATED and B_RESTORE_BACKGROUND_IMAGE
messages to update the Desktop text color.
Change-Id: I122dbeab668244772012656a59cbba3050245f44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8885
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
