* Weaken notice about API stability. A few public APIs in here now.
* Prune out APIs from the docs that are private in nature
* Enable markdown mode and ensure `--` options are quoted so they are
rendered as two dashes in the HTML.
Previously, PosMarker callbacks ran even when the assembler failed to
assemble its contents due to insufficient space. This was problematic
because when Assembler::compile() failed, the callbacks were given
positions that have no valid code, contrary to general expectation.
For example, we use a PosMarker callback to record VM instruction
boundaries and patch in jumps to exits in case the guest program starts
tracing, however, previously, we could record a location near the end of
the code block, where there is no space to patch in jumps. I suspect
this is the cause of the recent occurrences of rare random failures on
GitHub Actions with the invariants.rs:529 "can rewrite existing code"
message. `--yjit-perf` also uses PosMarker and had a similar issue.
Buffer the list of callbacks to fire, and only fire them when all code
in the assembler are written out successfully. It's more intuitive this
way.
rb_backtrace_t is 32B, so it fits well in a 80B slot.
There is some unused spaces but given Backtrace objects are
rarely held onto it should be inconsequential and avoid
the malloc churn.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
The previous implementation was using the pointer given
by `DATA_PTR` in all cases. But in the case of an embedded
TypedData, that pointer is garbage, we need to use RTYPEDDATA_GET_DATA
to get the proper data pointer.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
The struct is 16B, so they will use the 80B size pool, so on paper it
wastes 80 - 32 - 16 = 52B, however most malloc implementations will
either pad sizes or use an extra 16B for each segment, so in practice
the waste isn't that big. Also `Backtrace::Location` are rarely held
on for long, so avoiding the malloc churn help performance.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
Checking the past 10 builds in Travis CI arm64, it looks stable. So, disable
`allow_failures`.
Also sorted the order of the jobs for the priority. The arm64 is the first. And
I would like to run arm32 using the arm64 pipeline a bit later after the
arm64 using the same arm64 pipeline. So, the arm32 is the last.
Some code out there blind calls `force_encoding` without checking
what the original encoding was, which clears the coderange uselessly.
If the String is big, it can be a rather costly mistake.
For instance the `rack-utf8_sanitizer` gem does this on request
bodies.
In the past, I saw that the 2nd arm64 pipeline was unstable. Now I want to try
it to check if it is stable enough to run again.
As far as I know, right now the only native arm64 cases are MacOS Arm
`macos-arm-oss` on GitHub Actions. And I want to add Linux arm64 case on
pull-request in CI.
Nobuyoshi Nakada
Alan Wu
Alan Wu
Kevin Newton
Mateus Pereira
git
ima1zumi
Peter Zhu
Burdette Lamar
Jean Boussier
Edwin Garcia
Jun Aruga
Koichi Sasada
Hiroshi SHIBATA
Juanjo Bazán
Hiroya Fujinami
tomoya ishida
Jemma Issroff