Rax

本文地址: https://www.laruence.com/2020/06/27/5963.html 转载请注明出处 PHP8 alpha1已经在昨天发布，相信关于JIT是大家最关心的，它到底怎么用，有什么要注意的，以及性能提升到底咋样？ 首先，我们来看一张图: 左图是PHP8之前的Opcache流程示意图， 右图是PHP8中的Opcache示意图， 可以看出几个关键点: PHP8的JIT是在Opcache之中提供的 目前PHP8只支持x86架构的CPU JIT是在原来Opcache优化的优化基础之上进行优化的，不是替代 事实上JIT共用了很多原来Opcache做优化的基础数据结构，比如data flow graph, call graph, SSA等，关于这部分，后续如果有时间，可以单独在写一个文章来介绍，今天就只是着重在使用层面。 下载安装好以后，除掉原有的opcache配置以外，对于JIT我们需要添加如下配置到php.ini： opcache.jit=1205 opcache.jit_buffer_size=64M opcache.jit这个配置看起来稍微有点复杂，我来解释下, 这个配置由4个独立的数字组成，从左到右分别是( 请注意，这个是基于目前alpha1的版本设置，一些配置可能会随着后续版本做微调 ): 是否在生成机器码点时候使用AVX指令, 需要CPU支持: 0:

　　prcesssor在运行时，假设program counter的值为a 0 , a 1 , ... , a n-1 ，每个ak表示相对应的instruction的地址。从a k 到a k+1 的变化被称为control transfer。一系列的control transfers被称为control flow。 　　exceptions是指一些event，这些event表明当前的system、processor或executing program存在某些状况（详见1.2）。exceptions会导致control flow的突变，典型的就是将控制从当前运行的程序或任务转移到exception handler的执行（详见1.1节）。在计算机程序中，我们设计了jump和branch，call和return；他们通过program state的变化，引起了control flow的突变。exceptions中的control flow的突变是通过system state的变化来引发的，这种control flow的突变被称为exception control flow。interrupt作为exceptions的一种，当由I/O devices complete引发interrupt后，I/O devices通过pin的变化给processor发送signal，并将exception

测试文件： https://www.lanzous.com/ib5y9cb 代码分析 1 __int64 __fastcall main(__int64 a1, char **a2, char ** a3) 2 { 3 signed int i; // [rsp+8h] [rbp-68h] 4 signed int j; // [rsp+Ch] [rbp-64h] 5 __int64 v6; // [rsp+10h] [rbp-60h] 6 __int64 v7; // [rsp+18h] [rbp-58h] 7 __int64 v8; // [rsp+20h] [rbp-50h] 8 __int64 v9; // [rsp+28h] [rbp-48h] 9 __int64 v10; // [rsp+30h] [rbp-40h] 10 __int64 v11; // [rsp+40h] [rbp-30h] 11 __int64 v12; // [rsp+48h] [rbp-28h] 12 __int64 v13; // [rsp+50h] [rbp-20h] 13 __int64 v14; // [rsp+58h] [rbp-18h] 14 __int64 v15; // [rsp+60h] [rbp-10h] 15 unsigned __int64 v16; // [rsp

测试文件： https://www.lanzous.com/ib5y9cb 代码分析 1 __int64 __fastcall main(__int64 a1, char **a2, char ** a3) 2 { 3 signed int i; // [rsp+8h] [rbp-68h] 4 signed int j; // [rsp+Ch] [rbp-64h] 5 __int64 v6; // [rsp+10h] [rbp-60h] 6 __int64 v7; // [rsp+18h] [rbp-58h] 7 __int64 v8; // [rsp+20h] [rbp-50h] 8 __int64 v9; // [rsp+28h] [rbp-48h] 9 __int64 v10; // [rsp+30h] [rbp-40h] 10 __int64 v11; // [rsp+40h] [rbp-30h] 11 __int64 v12; // [rsp+48h] [rbp-28h] 12 __int64 v13; // [rsp+50h] [rbp-20h] 13 __int64 v14; // [rsp+58h] [rbp-18h] 14 __int64 v15; // [rsp+60h] [rbp-10h] 15 unsigned __int64 v16; // [rsp

测试文件： https://www.lanzous.com/ib5y9cb 代码分析 1 __int64 __fastcall main(__int64 a1, char **a2, char ** a3) 2 { 3 signed int i; // [rsp+8h] [rbp-68h] 4 signed int j; // [rsp+Ch] [rbp-64h] 5 __int64 v6; // [rsp+10h] [rbp-60h] 6 __int64 v7; // [rsp+18h] [rbp-58h] 7 __int64 v8; // [rsp+20h] [rbp-50h] 8 __int64 v9; // [rsp+28h] [rbp-48h] 9 __int64 v10; // [rsp+30h] [rbp-40h] 10 __int64 v11; // [rsp+40h] [rbp-30h] 11 __int64 v12; // [rsp+48h] [rbp-28h] 12 __int64 v13; // [rsp+50h] [rbp-20h] 13 __int64 v14; // [rsp+58h] [rbp-18h] 14 __int64 v15; // [rsp+60h] [rbp-10h] 15 unsigned __int64 v16; // [rsp

历史的发展 12~13 年，飞猪核心业务主要基于 PC 平台，前后端研发协作核心痛点在于动态模板的编写，不同团队前后端常围绕 “套模板” 工作的归属引发矛盾。 到 14、15 年 All in 无线的过程中，为了解决从 PC 时代复杂行业数据到无线网关的快速转换，飞猪成立了无线服务端团队来完成数据到端侧的胶水层工作，可很好解决系列问题，但是持续重复的包接口也让无线服务端面临的成长和沉淀问题，不太可持续的。 16、17 年无线服务端技术建设稳定后，也由于上述问题，接口封装的工作逐步由下放到行业后端同学，随着 H5/Weex/iOS/Android 多端发展，各自对接口的诉求难以一致，出现通过 Node BFF 层来承接胶水问题，但前端运维能力不强、长尾机器的浪费导致很难全量 BFF 化。 到 18 年飞猪平台化改造完成，业务由纵向行业变成横向平台承接，需求的落地需要经过多方的协作和排期，中间层的碎片化也更加严重，对前后端协作成本带来了更大的挑战，同时不能通过单领域问题的解决方案(如下单页解决方案)来解决其他业务层问题， 急需一轻量通用的方案来解决日益严重的胶水层的协作 。 建设目标 基于以上背景与问题分析，飞猪去年5月份启动了 「天空之城」- Serverless 技术体系建设专项，项目总体目标： 构建飞猪 Serverless 研发基础设施，赋能上层产品/平台，推动前端/后端、业务

简介 KiUserExceptionDispatcher 是SEH分发器的用户模式的负责函数。当一个异常发生的时候，该异常将生成一个异常事件，内核检查该异常是否是由于执行用户模式代码导致的。如果是这样的话，内核修改栈上的trap frame，因此当内核从中断或者异常返回的时候，线程将从KiUserExceptionDispatcher 函数执行而不是导致异常的指令。内核将另外安排几个参数(一个 PCONTEXT 和一个 PEXCEPTION_RECORD)，它们描述了异常发生时机器的状态，而且在线程返回到用户模式之前被传递给KiUserExceptionDispatcher 函数。 一旦内核模式栈展开，而且指令转移到用户模式的KiUserExceptionDispatcher 函数，该函数通过调用一个本地的函数RtlDispatchException来处理异常，RtlDispatchException是用户模式异常处理逻辑中的核心函数。如果异常被成功分发的话(也就是SHE 链表中有一个函数宣称可以处理该异常)， RtlDispatchException调用RtlRestoreContext 函数实现最终的用户模式上下文的设置，该函数只是加载给定的上下文中的寄存器到到处理器的体系结构执行状态中。 否则，通过调用 NtRaiseException 函数，异常重新被提交到内核模式

本文是《Go语言调度器源代码情景分析》系列的第18篇，也是第四章《Goroutine被动调度》的第1小节。 前一章我们详细分析了调度器的调度策略，即调度器如何选取下一个进入运行的goroutine，但我们还不清楚什么时候以及什么情况下会发生调度，从这一章开始我们就来讨论这个问题。 总体说来，go语言的调度器会在以下三种情况下对goroutine进行调度： goroutine执行某个操作因条件不满足需要等待而发生的调度； goroutine主动调用Gosched()函数让出CPU而发生的调度； goroutine运行时间太长或长时间处于系统调用之中而被调度器剥夺运行权而发生的调度。 本章主要分析我们称之为被动调度的第1种调度，剩下的两种调度将在后面两章分别进行讨论。 Demo例子 我们以一个demo程序为例来分析因阻塞而发生的被动调度。 package main func start(c chan int) { c<-100 } func main() { c:=make(chan int) go start(c) <-c } 该程序启动时，main goroutine首先会创建一个无缓存的channel，然后启动一个goroutine(为了方便讨论我们称它为g2)向channel发送数据，而main自己则去读取这个channel。

【今日推荐】：为什么一到面试就懵逼！>>> 三种:行定位;反汇编后的地址; 行相关定位 行相关定位格式: [filename:][linenum|function] filename 文件名 如果有则是指明某个文件，可以是相对路径，也可以是绝对路径。如果匹配了多个匹配的文件，那么则会在多个文件设置多个断点。 linenum 或 function linenum 则就是在对应行设置断点 function 则是搜索当前文件的函数 label 则是搜索当前文件的 label:C++用于goto定位的 如果没有 filename : funcname 表示所有文件所有匹配的函数,包括重载，命名空间和类成员的函数 label 从当前栈帧进行搜索，如果程序没有执行不执行搜索 反汇编后的地址 break *address disassemble [/s /m /r] start,end disassemble start,end disassemble /m function disassemble /r function disassemble /s function 新版本支持 不支持文件名，搜索的是当前的断点所在栈帧。 int foo(int x) { switch(x) { case 1: return 2; case 2: return 3; default: return 42; }

前言 Hi，大家好，今天非常高兴能有机会作为讲师，来给大家分享关于《如何设计实现中后台搭建 PaaS 平台》这个话题。今天的分享将围绕阿里淘系技术部飞冰系列产品中的中后台搭建产品 iceluna 来进行展开。 个人介绍 在正式分享之前，先自我介绍一下。我是来自阿里淘系营销中后台团队的月飞，负责中后台搭建产品 iceluna，以及《阿里集团中后台搭建协议标准规范》的推广和落地。2013 年加入阿里巴巴聚划算，负责 PC & 无线详情。2016 年加入天猫，带领营销玩法团队，负责玩法、互动类型业务。2019 年加入淘系技术部，带领营销中后台团队，负责中后台业务，专注于中后台搭建产品建设。 话题介绍 今天的话题是搭建，以面向角色的不同大致可以分为面向运营和面向研发两类搭建产品。面向运营的搭建产品主要是以可视化配置 ( No-code ) 的方式进行完整页面搭建，如营销活动页面搭建。面向研发的搭建产品主要以低代码开发 ( Low-code ) 的方式，搭建“中后台系统”或者“无线模块”，如商家、小二后台系统的搭建，无线 Rax 模块的搭建。今天我这边的话题是中后台系统搭建，跟营销活动类页面的搭建在面向角色和搭建模式上是非常不同的，接下来主要围绕 “ iceluna 产品 ” 和 “ PaaS 平台建设 ” 2 个维度来展开分享。 分享大纲 这是我分享的大纲，我会先对 iceluna