Move observability-relevant structure fields to the top

[P403n1x87]

Some structures have fields that are used by out-of-process tools, like Austin. Having these fields defined after some more complex structures makes it hard to maintain these tools. With this change, we move the declaration of the most useful fields to the top of the structure definition. This reduces the amount of irrelevant information that the mentioned tools have to replicate to retrieve the actually useful data

[P403n1x87]

@markshannon @pablogsal I hope you don't mind if I tag you on this PR. I was looking into the changes required to support 3.12 in Austin and thought of proposing this change to make my life (and presumably that of those who maintain similar tools) easier.

[pablogsal]

Unfortunately this is not a bugfix so technically we cannot backport this unless @Yhg1s gives us greenlight.

[pablogsal]

@Yhg1s are you ok backporting this to 3.12?

[Yhg1s]

Hrrm, not really, partly because I'm really not sold on the usefulness of the change, and partly because I'm aware of software poking at these things so this is an ABI change. I'd rather not backport, but if you want to try and sell me on the usefulness feel free :)

[markshannon]

Did anyone benchmark this?

The interpreter frame is the hottest piece of memory in the VM, so care needs to be taken rearranging the fields.
The eval_breaker field is also quite hot, so moving it away from the front of the of the interpreter state may well harm performance. This PR is undoing the layout change in #104581.

The order of fields should not be part of the API or ABI (apart from not moving them during a release). They should (IMO) be arranged for performance.
In fact there is no guarantee that the fields will even continue to exist. We have added and removed fields freely in the past, and want the freedom to continue to do so.

Also, what fields are important, and too whom?
What if tool A wants field X and tool B wants field Y, then what?
The order of fields needs to be an internal implementation detail. Things are just too fragile otherwise.

If we want to expose the offset of certain fields to out-of-process tools, then we could put the offsets in a table.

[markshannon]

Why is there no issue for this?
Which fields "are used by of out process tools"?
This PR doesn't make it clear what is being moved before what and why.

[pablogsal]

Well, as I can see that this change is highly controversial, let's revert it until we all agree.

[pablogsal]

#105512 for the revert

[pablogsal]

This has been reverted

[P403n1x87]

@markshannon are there specific benchmark designed to measure the performance the structures involved in this change.

Did anyone benchmark this?

I did not benchmark this, nor I have an idea of why fields are where they currently are, since there are no comments in the source code. Without that information available, I took the liberty to move them at will. I appreciate one might want to invoke the principle of locality here, but without extra information I had to take a guess.

The order of fields should not be part of the API or ABI (apart from not moving them during a release). They should (IMO) be arranged for performance.

This is not a request to make fields part of the A(B/P)I

In fact there is no guarantee that the fields will even continue to exist. We have added and removed fields freely in the past, and want the freedom to continue to do so.

It is quite likely that the most interesting fields will always be there (they might change name, as they have done in the past, but they are essentially still there).

Also, what fields are important, and too whom? What if tool A wants field X and tool B wants field Y, then what? The order of fields needs to be an internal implementation detail. Things are just too fragile otherwise.

It would be hard to take opinions out of this. As the maintainer of Austin, I have moved fields in the order that I makes the more sense to me (but hopefully to others as well). However I don't have a scientific answer to give for the ordering.

If we want to expose the offset of certain fields to out-of-process tools, then we could put the offsets in a table.

That would be great, but as far as I understand this is something that will perhaps come in the future. Here I'm looking for something that can go in 3.12.

[markshannon]

That would be great, but as far as I understand this is something that will perhaps come in the future. Here I'm looking for something that can go in 3.12.

Adding a new symbol might be more acceptable than moving fields around, regarding ABI compatibility.
But that's @Yhg1s decision.

[markshannon]

@P403n1x87
Want to make a list of the fields you need to access?
What's the best way to make information about offsets and the like visible to out-of-process tools?
We discussed a similar problem in #100987

[P403n1x87]

@P403n1x87 Want to make a list of the fields you need to access?

The list of fields that I'm currently relying on can be inferred from https://github.com/P403n1x87/austin/blob/b48d980f6f3d0808d9221ee611a9c3094e02bb50/src/version.h#L196-L306

What's the best way to make information about offsets and the like visible to out-of-process tools? We discussed a similar problem in #100987

I've shared my thoughts in this comment #100987 (comment). I think a symbol/section like _PyRuntime pointing to an offset structure would be enough.

[markshannon]

Want to make an issue for adding that info?