I noticed that the first page of low memory never gets hugified,
because the arena gets setup before main, and we don't know what to
mark huge until we've initialized the runtime options.
By setting the high water mark to 1 below the start of the low memory
arena, and only updating it when we *are* marking pages huge, we can
ensure that the right pages get marked.
I also replaced some jemalloc magic that I had never previously understood
with a simpler (to me) equivalent.
Reviewed By: @jdelong
Differential Revision: D967121
We carefully "enhugen()" portions of the tc. The problem is that low_malloc
maintains a high water mark, and every time it crosses into a new huge page
it marks everything up to the new high water mark huge. Since we allocate the
tc using sbrk, which allocates above the high water mark, the next time
low_malloc extends its arena, we mark the whole tc huge.
This adds some code to update the high watermark around the tc, and adds a runtime option to limit the number of huge pages used by low memory.
Differential Revision: D912684
Lots of scripts running in cli mode can quickly use up the huge page pool. Its better to not do that by default.
Even in server mode, it seems very suspicious to have large, thread-private segments of huge
pages. This should place heavy demands on the system's huge page resources,
and more worryingly, demand that scales up as threads go active.
Differential Revision: D885896
I was learning from @jdelong and he said that you should use
double quotes for local includes and angle brackets for library
includes. I asked why our code was the way it was, and he said he wanted
to clean it up. I beat him to it :)
Conflicts:
hphp/runtime/base/server/admin_request_handler.cpp
hphp/runtime/vm/named_entity.h
PAGE_SIZE isn't portable -- e.g. my ARMv8 sysroot doesn't define it. I'm
replacing it in the way the Linux manpage recommends. This should work
on a wide variety of platforms. For example, it works on OS X.
... is that once you put them into the codebase, the odds of them
showing up where you dont want them go up dramatically.
With a gcc 4.7.1 -O0 build I hit a consistent crash in production
where debugBacktrace had stepped too far, thinking that the
first non-vm frame was in fact a vm frame. It did so because
it looked at the word above the frame, and saw that it contained
c_Continuation::kMagic.
It turns out that fixupWork's isVMFrame left kMagic in $rdx if the
frame really was a generator ($rdx was dead, but still). We then
return from the tc via a serviceReq that doesnt need $rdx (so doesnt
set it), and then (with a following wind, so that $rdx hasnt been
smashed yet) enterTCHelper stores $rdx in info.args[1].
By another staggering coincidence, info.args[1] is at exactly the
right address to make the call into enterTCHelper /look/ like a
a continuation (based on kMagic). So if we then have a catch
which re-enters the TC there's a good chance kMagic is still there
and the next debugBacktrace (or uncaught exception) will crash.
This diff rewrites everything in terms of the C++ stack; we
now say that its a VM frame if its not on the C++ stack.
This change is mostly for FB internal organizational reasons.
Building is not effected beyond the fact that the target now
lands in hphp/hhvm/hhvm rather than src/hhvm/hhvm.
mwilliams