解释器生成bytecode时是否需要对bytecode指令做对齐处理？

解释器生成字节码时是否会做对齐处理？ #

绝大多数通用语言的解释器默认不会对字节码做对齐填充：

• 字节码的设计优先级首先是降低存储、传输体积，通常采用紧凑编码规则，1字节 opcode 后跟对应长度的操作数，中间无任何填充，比如CPython的字节码、Lua的字节码均采用这类设计。
• 仅少数面向极致性能优化、或者适配特定硬件（比如部分强制要求对齐的嵌入式芯片）的自研解释器会做对齐处理，通常是固定单条指令占4字节/8字节，操作数不足时填充空操作指令NOP，但这类实现非常少见。

变长编码字节码在循环switch解释场景下的处理器读取影响 #

整体来看几乎不会产生可感知的不利影响，只有极端场景下会有微小开销，具体说明如下：

• 现代处理器的硬件层面已经对非对齐字节访问做了深度优化，只要内存地址在L1缓存中命中，非对齐的1/2/4/8字节读取的延迟和对齐访问基本一致，不会产生额外惩罚。
• 唯一会产生额外开销的场景是操作数刚好跨缓存行/内存页边界，此时处理器需要读取两个缓存行/页才能拼接出完整的操作数，会多产生1~2个周期的延迟，但这类场景的出现概率极低，实际测试对解释器整体性能的影响通常低于1%，远小于指令分发、操作数栈操作等其他解释器逻辑的开销。
• x86架构天生支持非对齐内存访问，无硬性访问错误；ARMv7及之后的架构也默认开启非对齐访问支持，只有开启了严格对齐配置的嵌入式设备才会触发访问错误，消费级设备基本不存在此类问题。

如果是极端追求解释性能的场景，可以在生成字节码时手动对大于1字节的操作数做自然对齐：即在opcode和操作数之间填充1~3字节的NOP，保证操作数的起始地址是自身长度的整数倍，但这类优化的收益极低，主流解释器均没有采用。

内容的提问来源于stack exchange，提问作者Евгений Павлов