DEV Community: собачья будка

как сконвертировать пачку изображений в webp

собачья будка — Wed, 30 Mar 2022 07:14:26 +0000

для этого понадобится либа cwebp, которая принимает на вход степень сжатия (1..100), имя входного и выходного файлов, и простой баш цикл.
соберем все картинки в одну директорию и перейдем в нее, после чего опишем скрипт:

for file in *
do
cwebp -q 100 "$file" -o "${file%.png}.webp"
done

как наложить блюр в фигме

собачья будка — Wed, 30 Mar 2022 07:12:41 +0000

для формы блюра используем любую фигуру (R):

и выделим необходимое для замутнения место:

изменим цвет заливки на белый с полупрозрачностью в 1%:

и добавим эффект background blur:

клик на иконку позволяет настраивать степень блюра. well done!

генерируем xlsx из rss фида

собачья будка — Sun, 27 Mar 2022 06:22:06 +0000

нагулял задачу генерации таблиц из rss фида, парсеры выходят на арену. план такой: из терминала кормим скрипт набором аргументов с линком к rss фиду и его настройками, добавляем прогресс бары для отзывчивости, на выход отдаем сгенерированную таблицу.

сперва набросаем пачку зависимостей:

yarn add rss-parser
yarn add --dev exceljs moment posthtml progress request request-promise yargs

за дело! импортирую переменные и определяю парсер:

const ExcelJS = require('exceljs')
const Parser = require('rss-parser')
const posthtml = require('posthtml')
const rp = require('request-promise')
const moment = require('moment')
const ProgressBar = require('progress')
const yargs = require("yargs")

const parser = new Parser()

описываю обязательные и не очень аргументы, определяю входную функцию и на ходу рассказываю о прогрессе в терминал:

const options = yargs
    .usage(`Usage: -f <rss uri>`)
    .option('f', {
        alias: 'feed',
        describe: 'RSS feed uri',
        type: 'string',
        demandOption: true
    })
    .option('a', {
        alias: 'amount',
        describe: 'Needed RSS feed posts amount',
        type: 'string'
    })
    .option('n', {
        alias: 'outputFileName',
        describe: 'XLS output file name',
        type: 'string'
    })
    .option('o', {
        alias: 'cellOptions',
        describe: 'Sheet cell additional options',
        type: 'array'
    })
    .argv

process.stdout.write(`great options, bruh, let's start already!\n`)

entry(options.feed, options.amount, options.outputFileName, options.cellOptions)

главная функция будет принимать на вход обязательный линк на фид и необязательные количество постов, имя таблицы на выходе и набор кастомных настроек для ячеек. назначаю нужные столбцы и их ключи:

let entry = async (rssFeed, amount = 5, outputFileName = 'result', cellOptions = []) => {
    process.stdout.write(`parsing your rss feed...\n`)
    let feed = await parser.parseURL(rssFeed)

    process.stdout.write(`creating excel workbook...\n`)
    const workbook = new ExcelJS.Workbook()
    const worksheet = workbook.addWorksheet(outputFileName)
    worksheet.columns = [{
            header: 'text',
            key: 'col_text'
        },
        {
            header: 'url',
            key: 'col_url'
        },
        {
            header: 'images',
            key: 'col_images'
        },
        {
            header: 'time',
            key: 'col_time'
        }
    ]
}

приступаю к генерации новых строк и добавляю тикающий прогресс бар:

process.stdout.write(`generating posts from rss feed...\n`)
let generatedRows = await generatePostsMetaFromFeed(feed, amount)
let generatedRowsBar = new ProgressBar('[:bar] :current/:total table rows generated\n', {
    incomplete: ' ',
    complete: '#',
    total: generatedRows.length
})

функция generatePostsMetaFromFeed займется пирсингом элементов фида и генерацией набора с нужными таблице полями:

let convertFeedToPosts = feed => [...feed.items.map(item => item.link)] // для пагинации по страницам фида понадобятся линки

let generatePostsMetaFromFeed = async (feed, amount) => {
    let res = []

    let posts = []
    let feedLink = feed.link

    if (amount > 10) {
        process.stdout.write(`wow, so much posts? taking care of it...\n`)
        let pages = Math.round(amount / 10) // пагинация для доступа к последующим страницам фида
        let pagesLoadingBar = new ProgressBar('[:bar] :current/:total processed\n', {
            incomplete: ' ',
            complete: '#',
            total: pages
        })

        posts.push(...convertFeedToPosts(feed))

        process.stdout.write(`loading needed pages...\n`)
        for (let i = 2; i <= pages; i++) {
            await rp(encodeURI(`${feedLink}?feed=rss&paged=${i}`))
                .then(async rssPage => {
                    let parsedRSSFeed = await parser.parseString(rssPage)
                    let isLastPage = i === pages

                    if (isLastPage) {
                        let modItems = parsedRSSFeed.items.filter((_, index) => index < amount % 10)

                        posts.push(...convertFeedToPosts({
                            items: modItems
                        }))
                    } else {
                        posts.push(...convertFeedToPosts(parsedRSSFeed))
                    }

                    pagesLoadingBar.tick()
                })
                .catch(err => {
                    console.error('huh, rss pagination failed', err.code)
                })
        }
    } else {
        process.stdout.write(`not a lot of posts, gonna be quick!\n`)
        posts.push(...convertFeedToPosts({
            items: feed.items.slice(0, amount)
        }))
    }

    process.stdout.write(`time to generate some text for our table!\n`)
    let postsHandlingBar = new ProgressBar('[:bar] :current/:total posts handled\n', {
        incomplete: ' ',
        complete: '#',
        total: posts.length
    })

    for (let i = 0; i < posts.length; i++) {
        let postLink = posts[i]
        let title, description, image

        await rp(postLink)
            .then(html => {
                process.stdout.write(`wuush, working on it...\n`)
                posthtml().use(tree => { // парсим дерево и только нужные таблице значения нод
                    tree.match({
                        tag: 'title'
                    }, node => {
                        title = node.content[0]
                    })
                    tree.match({
                        attrs: {
                            name: 'description'
                        },
                        tag: 'meta'
                    }, node => {
                        description = node.attrs.content
                    })
                    tree.match({
                        attrs: {
                            property: 'og:image'
                        },
                        tag: 'meta'
                    }, node => {
                        image = node.attrs.content
                    })
                }).process(html)

                postsHandlingBar.tick()
            })
            .catch(err => {
                console.error('huh, post parsing failed', err)
            })

        res.push({
            title,
            description,
            image,
            link: postLink
        })
    }

    return res
}

строки сгенерированы, пора вернуться во входную entry функцию и прикрутить их к инстансу worksheet, используя метод addRow:

process.stdout.write(`making some rows for your sheet...\n`)
for (let i = 0; i < generatedRows.length; i++) {
    let {
        title,
        description,
        image,
        link
    } = generatedRows[i]
    let columnText = `${title}\n\n${description}\n\n${link}`

    if (cellOptions.length) {
        cellOptions.forEach(cOption => {
            if (cOption === 'noImage') {
                image = ''
            }
            if (cOption === 'noOGCard') {
                link = ''
            }
        })
    }

    worksheet.addRow({
        col_text: columnText,
        col_url: link,
        col_images: image,
        col_time: moment().add(i, 'days').format('DD/MM/YYYY hh:mm').toString()
    })

    generatedRowsBar.tick()
}

lift off! теперь можно отдавать таблицу:

process.stdout.write(`creating your ${outputFileName} file...\n`)
await workbook.xlsx.writeFile(`${outputFileName}.xlsx`)
    .then(() => {
        process.stdout.write(`${outputFileName} created allright!\n`)
    })
    .catch((err) => {
        process.stdout.write('huh, creating error: ', err)
    })

process.stdout.write(`all done, love!\n`)

таблица в кармане, profit!

исходный код: https://github.com/arkatriymfalnaya/xlsx-from-rss-generator

очередной слайдер, которого никто не просил

собачья будка — Sat, 26 Mar 2022 06:17:52 +0000

натыкаясь на вакансии от разных контор, я периодически берусь за тестовые задания, чтобы поразвлечься. в этот раз выбор пал на, кто бы сомневался, очередной слайдер. ну и пусть.

собираем проект, пара библиотек нам пригодится:

npm init
yarn add path express pug path
yarn add --dev nodemon

сразу добавим dev скрипт в package.json, который будет стучаться к нашему сервер-скрипту:

"scripts": {
    "dev": "nodemon src/server.js"
}

создадим папку src и файл server.js, в котором опишем наш сервер и движок для pug шаблонов:

const express = require('express')
const path = require('path')
const fs = require('fs')

const app = express()
const port = '8000'

app.listen(port, () => {
    console.log(`Listening on http://localhost:${port}`)
})

app.set('views', path.join(__dirname, 'views'))
app.set('view engine', 'pug')
app.use(express.static(path.join(__dirname, 'public')))

app.get('/', (_, res) => {
    try {
        let paths = fs.readdirSync(path.join(__dirname + '/public/images/')) // там будут храниться наши картинки для слайд-шоу
        let combinedPaths = paths.map(p => `images/${p}`)

        res.render('index', {
            imagesPaths: combinedPaths
        })
    } catch (err) {
        throw err
    }
})

самое время набросать разметку. одна центрирующая обертка, одна секция самого слайдера, контролы и сами слайды, которые отдаются серверным скриптом:

doctype html
html(lang='en')
  head
    meta(charset='utf-8')
    link(rel='stylesheet' href='styles/index.css')
    meta(name='viewport', content='width=device-width, initial-scale=1, shrink-to-fit=no')
  body
    main.wrapper
        section.slider
            each src in imagesPaths
                article.slider__item.slider__item--appear.slide
                    figure
                        img(src=src alt='pic')
            section.slider__controls
                button
                button
    script(type='module' src='scripts/index.js')

переходим к самому вкусному - к интерактивности, которую возьмет на себя скрипт scripts/index.js. сперва обезопасим себя и дождемся загрузки DOM дерева:

document.addEventListener('DOMContentLoaded', () => {
  …
}, false)

вытащим из дерева нужные ноды, объявим переменные для интервала и учёта текущего индекса слайда:

const slidesList = document.querySelectorAll('.slider__item')
const controlsList = document.querySelector('.slider__controls').children
const leftControl = controlsList[0]
const rightControl = controlsList[1] // больше двух детей не предполагается

let interval = null
let currentIndex = 1

в конце скрипта инициализируем события и рендеринг самого слайдера:

document.addEventListener('keydown', e => {
    if (e.key === 'ArrowLeft') moveSlider('left') // переключение левой стрелкой
    if (e.key === 'ArrowRight') moveSlider('right') // переключение правой стрелкой
    if (e.key === ' ' && e.target.nodeName !== 'BUTTON') {
        if (interval) {
            stopSliding() // остановка на текущем слайде по нажатию на пробел
        } else {
            proceedSliding() // продолжение слайд-шоу, если была остановка
        }
    }
})
leftControl.addEventListener('click', () => moveSlider('left'), false)
rightControl.addEventListener('click', () => moveSlider('right'), false)

initSlider(slidesList)

столько функций еще не написано! надо исправлять:

const initSlider = slides => {
    if (currentIndex > slides.length) currentIndex = 1
    if (currentIndex < 1) currentIndex = slides.length

    updateSlider(slidesList)
}

const moveSlider = to => {
    if (to === 'right') updateCurrentIndex('right')
    else updateCurrentIndex('left')

    initSlider(slidesList)
}

…

const stopSliding = () => {
    clearInterval(interval)
    interval = null // очищаем интервал, чтобы остановить слайд-шоу

    slidesList[currentIndex - 1].classList.add('slide--stopped')
}

const proceedSliding = () => {
    interval = setInterval(() => {
        updateCurrentIndex('right')
        initSlider(slidesList)
    }, 3000)
    slidesList[currentIndex - 1].classList.remove('slide--stopped')
}

многие участки дублируются, потому выносим их в отдельные хендлеры:

const updateSlider = slides => {
    clearInterval(interval)

    for (let i = 0; i < slides.length; i++) {
        slides[i].classList.add('slider__item--inactive') // стили класса будут удалять слайд из разметки
        slides[i].classList.remove('slide--stopped')
    }

    slides[currentIndex - 1].classList.remove('slider__item--inactive')

    interval = setInterval(() => { // переопределяем интервал, ведь слайд-шоу не просто так шоу
        updateCurrentIndex('right')
        initSlider(slidesList)
    }, 3000)
}

…

const updateCurrentIndex = to => {
    if (to === 'right') currentIndex++
    else currentIndex--
}

ой, почти все! добавим стили и анимации для появления слайдов:

* {
    box-sizing: border-box;
}

body, section, figure, button {
    padding: 0;
    margin: 0;
}

.wrapper {
    width: 100vw;
    height: 100vh;
    display: flex;
    align-items: center;
    justify-content: center;
    background-color: rgba(0, 0, 0, 1);
}

.slider {
    position: relative;
    width: 100%;
    height: 540px;
}

.slider__views-counter {
    position: absolute;
    top: -28px;
    left: 0;
    margin: 0;
    margin-left: 14px;
    font-family: 'Helvetica';
    font-size: 20px;
    line-height: 24px;
    color: white;
}

.slider__item {
    display: flex;
    height: 100%;
}

.slider__item--inactive {
    display: none;
}

.slider__item--appear {
    animation-name: slide-appearing;
    animation-duration: 1.5s;
}

.slide {
    align-items: center;
}

.slide--stopped {
    outline: 5px auto Highlight;
}

.slide figure {
    width: 100%;
    height: 100%;
    display: flex;
    justify-content: center;
    align-items: center;
}

.slide figure img {
    max-width: 100%;
    width: auto;
    max-height: 100%;
    height: auto;
}

.slider__controls {
    position: absolute;
    z-index: 2;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    margin: auto;
    display: flex;
    align-items: center;
    justify-content: space-between;
    width: 100%;
}

.slider__controls button {
    position: relative;
    width: 14%;
    max-width: 80px;
    height: 40%;
    border: none;
    background: transparent;
    cursor: pointer;
    border-radius: 8px;
    background-color: rgba(255, 255, 255, .14);
}

.slider__controls button:hover {
    background-color: rgba(255, 255, 255, .18);
}

.slider__controls button:active {
    box-shadow: 0px 0px 22px rgba(0, 0, 0, 0.2);
}

.slider__controls button::after {
    content: '';
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    margin: auto;
    width: 60%;
    height: 60%;
    background-image: url(/icons/arrow.svg);
    background-size: 100% 100%;
    background-repeat: no-repeat;
    filter: invert();
}

.slider__controls button:nth-child(2)::after {
    transform: rotate(180deg);
}

@keyframes slide-appearing {
    from {
        opacity: .2;
    }
    to {
        opacity: 1;
    }
}

@media screen and (min-width: 1020px) {
    .slider {
      width: 80%;
      max-width: 1020px;
    }

    .slider__views-counter {
        margin-left: 0;
    }

    .slider__controls button {
        max-width: 40px;
    }
  }

пора бы глянуть, чего уже там нарисовалось то. запустим yarn dev и перейдем по http://localhost:8000:

а что, дизайн вышел покурить? ну и пусть, ведь важнее, что внутри.

как я избавлялся от экстремизма в блоге

собачья будка — Thu, 24 Mar 2022 13:28:44 +0000

по мотивам недавних судебных решений блог моей компании о соцсетях и вокруг попадал под длящееся правонарушение. неопределенность по поводу нужных действий от других компаний и отсутствие решения суда сбивало с толку, потому, прежде чем скрывать все статьи с упоминаниями продуктов компании M**a, было решено подстраховаться иноагентскими методами.

первым вариантом был скрипт, которому можно скормить статьи и регуляркой добавить сноски всем упоминаниям экстремистских продуктов. с этой идеи начал, этой идеей и закончил.

wordpress хранит статьи в базе, доступ из админки по вкладке записи. встроенные инструменты позволяют экспортировать и импортировать контент из базы в удобном xml формате, осталось разобраться со структурой. для парсинга разогнал библиотеку fast-xml-parser:

const data = fs.readFileSync(path.join(__dirname, fileName), 'utf8')
const parser = new XMLParser()

let jObj = parser.parse(data)

рассмотрев дерево, выделил нужные мне ветки: wp:postmeta и content:encoded, дело за малым. пишем простую регулярку, выискивающую подстроку, которая не начинается с символа [ (используется для markdown тегов), имеет одно вхождение из набора названий запрещенных продуктов (название1|название2|название3) и любое окончание для русской вариации [а-яА-Я]*. для туллтипов использовался wordpress плагин Shortcodes Ultimate. поскольку реплейсить придется для нескольких веток, выносим эту исторую в отдельную функцию и обрабатываем корнер кейсы:

let replaceWithToolbar = str => str.replace(/[^\[|\/](meta|instagram|facebook|инстаграм|мета|фейсбук)[а-яА-Я]*/gi, (subStr, _, subStrIndex) => {
  let nextSymbol = str[subStrIndex + subStr.length]

  if(str[subStrIndex - 3] + str[subStrIndex - 2] + str[subStrIndex - 1] + str[subStrIndex] === 'www.') return subStr

  let space = '<code style="letter-spacing: -7px;"> </code>'

  let start = subStr[0]
  let end = nextSymbol === ' ' ? space : ''
  let updatedStr = subStr.substring(1)

  let tooltipText =
    subStr.includes('нстагра') || subStr.includes('ейсб') || subStr.includes('nstagr') || subStr.includes('aceboo')
      ? 'Продукт принадлежит организации, признанной экстремистской на территории Российской Федерации.'
      : 'Организация признана экстремистской на территории Российской Федерации.'

  return `${start}${space}[su_tooltip text="${tooltipText}" text_align="center"]${updatedStr}[/su_tooltip]${end}`
})

остается только грязно обновить исходные ветки на получившиеся:

let metasArray = jObj.rss.channel.item['wp:postmeta']
let newMetasArray = metasArray.map(m => {
  if(m['wp:meta_key'] === '_crb_description' || m['wp:meta_key'] === '_crb_short_description') {
    let newMeta = replaceWithToolbar(m['wp:meta_value'])
    m['wp:meta_value'] = newMeta
  }

  return m
})
jObj.rss.channel.item['wp:postmeta'] = newMetasArray

let content = jObj.rss.channel.item['content:encoded']
let newContent = replaceWithToolbar(content)
jObj.rss.channel.item['content:encoded'] = newContent

после чего билдим дерево в новый xml и пишем в файл:

const builder = new XMLBuilder({ processEntities:false })
const xmlContent = builder.build(jObj)
fs.writeFileSync(path.join(__dirname, `output_${fileName}`), xmlContent)

ну, вроде подстраховались!

исходный код: https://github.com/arkatriymfalnaya/avoid-extremism

architectural styles and the design of network-based software architectures. representational state transfer [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:43 +0000

Вольный перевод главы диссертации Roy Thomas Fielding "Representational State Transfer (REST)"

Representational State Transfer (REST)

Эта глава представляет и конкретизирует Representational State Transfer (REST) - архитектурный стиль для распределенных гипермедийных систем, описывает принципы разработки программного обеспечения, следуя REST, а также описывает ограничения взаимодействия для сохранения этих принципов, в то же время сопоставляя их с ограничениями других архитектурных стилей. REST - это гибридный стиль, полученный из описанных в третьей лаве архитектурных стилей и определяющий единый интерфейс соединителя коннектора в сочетании с дополнительными ограниченияеми. Структура архитектуры ПО из первой главы используется для определения архитектурных элементов REST изучения примеров просессов, коннекторов и представлений данных прототипных архитектур.

5.1 Процесс выведения REST

Обоснование проектирования, лежащее в основе веб архитектуры, может быть описано архитектурым стилем, который состоит из набора применяемых к элементам ограничений. Изучая влияние каждого ограничения по мере го добавления к развивающемуся стилю, мы может определять свойства, индуцированные ограничениями веба. Затем для формирования нового архитектурного стиля, который лучше отражает свойства современной веб архитектуры, могут быть применены дополнительные ограничения. Эта секция предоставляет общий обзор REST путём рассмотрения процесса выведения его как архитектурного стиля. Конкретные ограничения, из которых состоит REST, будут описаны в последующих разделах .

5.1.1 Начиная с Нулевого Стиля

Как для построек, так и для программного обеспечения существует два общих взгляда на процесс архитектурного проектирования. Первый: проектировщик начинает с пустого состояния, рисовальной или чертежной доски и, пока потребности предполагаемой системы не будут удовлетворены, выстраивает архитектуру из уже знакомых компонентов. Второй: проектировщик отталкивается от потребностей системы без ограничений, после чего постепенно определяет и применяет ограничения к её элементам, чтобы разграничить область проектирования и позволить силам, влияющим на поведение системы, течь естественным образом, в гармонии с системой. Первый взгляд подразумевает креативное и неограниченное видение, второй - сдержанность и понимание контекста нужной системы. REST был разработан с помощью последнего. Фигуры с 5-1 по 5-8 графически описывают, как примененные ограничения разграничивают процесс представления архитектуры в качестве инкрементального набора ограничений.

Нулевой стиль (Изображение 5-1) - это просто пустой набор ограничений. С точки зрения архитектуры, нулевой стиль описывает систему, в которой четкая граница между компонентами не установлена. Это начальная точка для нашего описания REST.

5.1.2 Клиент-сервер

Первыми добавленными к нашему гибридному стилю ограничениями будут ограничения клиент-серверного архитектурного стиля (Изображение 5-2), описанные в Секции 3.4.1. Принцип, лежащий в основе клиент-серверных ограничений, заключается в разделении интересов. Разделением интересов пользовательского интерфейса от интересов хранилища данных, мы улучшаем портативность пользовательского интерфейса на несколько платформ и улучшаем масшабируемость, упрощая серверные компоненты. Для веба наиболее важным, пожалуй, является то, что разделение позволяет компонентам развиваться независимо, тем самым поддерживая требования расширяемости интернета для нескольких организационных доменов.

5.1.3 Отсутствие состояния (Stateless)

Следующее ограничение клиент-серверного взаимодействия: коммуникация должна не иметь состояния по своей природе, следуя стилю client-stateless-server (CSS) из Секции 3.4.3 (Изображение 5-3), что подразумевает, что каждый запрос от клиента к серверу должен содержать всю необходимую для его понимания информацию и не может использовать хранящийся на сервере контекст. Потому состояние сессии полностью хранится на клиенте.

Это ограничение индуцирует свойства видимости, надежности и расширяемости. Видимость улучшается за счет того, что системе мониторинга не нужно выходить за пределы данных запроса, чтобы определить его полную природу. Надежность улучшается, потому что облегчается задача по восстановлению после частичных сбоев. Расширяемость улучшается, потому что отсуствие необходимости хранения состояния между запросами позволяет серверному компоненту быстрее освобождать ресурсы и еще больше упрощает реализацию, потому что серверу не приходится управлять использованием ресурсов между запросами.

Как и большинство архитектурных решений, ограничение в виде отсутствия состояния является компромиссом проектирования. Недостатком может быть то, что этот способ может снизить производительность сети из-за увеличения количества повторяющихся данных (per-interaction overhead), отправляемых в сериях запросов, поскольку эти данные нельзя оставлять на сервере в общем контексте. К тому же, хранение состояния приложения на стороне клиента уменьшает возможность контроля за поведением приложения со стороны сервера, поскольку приложение становится зависимым от правильности реализации семантики для нескольких версияй клиента.

5.1.4 Кэш

Для того, чтобы улучшить эффективность сети, мы добавляем ограничения кэша для формирования стиля client-cache-stateless-server из секции 3.4.4 (Изображение 5-4). Ограничения кэша требуют, чтобы данные внутри ответа на запрос были явно или неявно отмечены, как кэшируемые или некэшируемые. Если ответ кэшируемый - клиентскому кэшу дается право переиспользовать данные ответа для последующих эквивалентных запросов.

Преимущество от добавления ограничения кэша в том, что появляется возможность частично или полностью исключить некоторые взаимодействия за счет уменьшения средней задержки их серии, тем самым улучшая эффективность, расширяемость и воспринимаемую пользователем производительность. Компромисс, однако, заключается в том, что кэш может снизить надежность, если устаревшие данные в кэше значительно отличаются от данных, полученных при отправке запроса на непосредственно сервер.

Ранняя веб архитектура, как показано на изображении 5-5, определялась client-cache-stateless-server набором ограничений. Таким образом, для обмена статическими документами через интернет представленное для веб архитектуры до 1994 обоснование проектирования было сфокусировано на клиент-серверном взаимодействии без состояния. Протоколы для взаимного взаимодействия имели рудиментарную поддержку для кэшей без общего доступа, но не ограничивали интерфейс согласованным набором семантики для всех ресурсов. Вместо того, в вебе использовалась общая библиотека клиент-серверной реализации (CERN libwww) для обеспечения согласованности между веб приложениями.

Разработчики веб реализаций уже превзошли ранние методы проектирования. Кроме статических документов, запросы могли идентифицировать сервисы, которые динамически генерировали ответы, вроде image-maps [Кевин Хьюз] и server-side scripts [Роб МакКул]. Также была начата работа над промежуточными компонентами в виде прокси-серверов и общих кэшей, но для надежной связи те нуждались в расширених протоколов. Следующие разделы описывают ограничения, которые были добавлены к архитектурному стилю веба, для указания расширений, формирующих современную веб архитектуру.

5.1.5 Унифицированный интерфейс

Главной отличительной чертой REST стиля от остальных является, акцент на единый интерфейс между компонентами (Изображение 5-6). Применение такого принципа к интерфейсу компонент улучшает видимость взаимодействий и позволяет упростить архитектуру системы в целом. Реализации отделены от сервисов, которые они предоставляют, что способствует их независимому развитию. Компромисс в том, что унифицированный интерфейс снижает эффективность, поскольку информацию передается в стандартизированном виде, а не в виде, определенном под нужды приложения. Интерфейс REST был спроектирован для эффективной передачи крупного количества гипермедиа данных, частого случая в вебе, но не оптимален для других видов архитектурного взаимодействия.

Чтобы достчиь унифицированного интерфейса, на поведение компонентов должны быть наложены некоторые архитектурные ограничения. REST определяется четырьмя интерфейсными ограничениями: идентификация ресурсов; управление ресурсами через представления; самоописывающиеся сообщения; и гипермедиа, как двигатель состояния приложения. Эти ограничения будут обсуждены в секции 5.2.

5.1.6 Многоуровневая система

Для последующего улучшения поведения и требований расширяемости интернета, мы добавили ограчения уровневой системы (Изображение 5-7). Как описано в секции 3.4.2, уровневый системный стиль позволяет архитектуре состоять их иерархичных слоев путем особого поведения компонентов - каждый компонент не может "смотреть" за пределы уровня, с которым взаимодействует. Ограничивая знание о системе до одного уровня, мы обеспечиваем подложке незавимость и ограничиваем сложность системы в целом. Уровни могут быть использованы, чтобы оборачивать legacy сервисы и огорождать от них новые, упрощая компоненты за счет перемещения редкоиспользуемых функций в общий промежуточный уровень. Такие уровни также могут использоваться для улучшения расширяемости системы, обеспечивая балансировку нагрузки служб между несколькими сетями и процессорами.

Главным недостатом уровненой системы является то, что они увеличивают расходы и, соответстно, задержку при обработке данных, снижая воспринимаемую пользователем производительность. Для сетевой системы, поддерживающей ограничения кэширования, эти издержки можно компенсировать преимуществами общего кэширования в промежуточном уровне. Размещение общиъ кэшей на границах организационного домена может привести к значительному повышению производительности. Такие уровни также позволяют применять политики безопасности к данным, пересекающим эти границы, как того требуют файрволлы.

Комбинация многоуровневой системы и ограничений унифицированного интерфейса приводит архитектурные свойства к виду pipe-and-filter (секция 3.2.2). Хотя REST взаимодействие является двусторонним, потоки данных большого размера гипермедиа взаимодействия могут обрабатываться как сеть потоков данных с фильтрующими компонентами, выборочно примеяемыми к потокам для преобразования их содержимого. Внутри REST промежуточные компоненты могут активно преобразовывать содержимое сообщений, потому что сообщения самоописывающиеся и их семантика видна на промежуточных уровнях.

5.1.7 Код по требованию

Последним дополнением к нашему набору ограничений будет стиль code-on-demand из секции 3.5.3 (Изображение 5-8). REST позволяет клиенту расширяться функциональности клиента и выполнять код в виде апплетов или скриптов. Это упрощает клиентов, уменьшая количество необходимых для предварительной реализации фич. Благодаря возможности загрузки фич после деплоя, улучшается расширяемость системы. Однако, видимость также уменьшается, потому это ограничение внутри REST является опциональным.

Понятие опционального ограничения может показаться оксюмороном. Тем не менее, оно имеет предназначение при проектировании системы, охватывающей несколько организационных границ. Это значит, что, когда опциональное ограничение действует только для некоторой области системы, архитектура получает преимущество. Например, если все клиентское ПО внутри организации поддерживает Java-апплеты, то сервисы в этой организации могут быть сконструированы таким образом, чтобы они получали преимущества расширенной функциональности с помощью загружаемых классов Java. Однако, файрволл организации может не допустить передачу Java-апплетов из внешних источников, и, следовательно, для остальной части Интернета это будет выглядеть так, как будто эти клиенты не поддерживают код по требованию. Опциональное ограничение позволяет нам проетировать архитектуру, которая в общих случаях поддерживает желаемое поведение, но может быть отключена в некоторых контекстах.

5.1.8 Summary

REST состоит из набора рахитектурных ограничений, выбранных из-за присущих им свойст. В то же время, каждое из этих ограничений можно рассматривать отдельно, а описание их с точки зрения происхождения из общих архитектурных стилей облегчает понимание обоснования их выбора. Изображение 5-9 отображает ответвления ограничений REST в терминах сетевых архитектурных стилей, описанных в главе 3.

5.2 Архитектурные элементы REST

Стиль REST является абстракцией архитектурных элементов внутри распределенной гипермедийной системы. REST игнорирует детали реализации компонента и синтаксис протокола для лучшего фокусирования на ролях компонентов, их интерпретации значимых элементов данных, ограничений их взаимодействия с другими компонентами. REST охватывает фундаментальные ограничения компонентов, коннекторов и данных, которые определяют основу веб архитектуры и, таким образом, сущность его поведения как сетевого приложения.

5.2.1 Элементы данных

В отличие от распределенного объектного стиля, где все данные скрываются внутри компонентами обработки, природа и состояние архитектурных элементов данных - ключевой аспект REST. Обоснование такого проектирования можно увидеть в природе самих распределенных гипермедиа. Когда выбирается ссылка, информация должна переместиться из места хранения в место, где она будет использоваться пользователем. В отличие от многих других парадигм распределенной обработки, где возможно и обычно более эффективно перемещать сам «агент обработки» (например, мобильный код, хранимую процедуру, выражение поиска и т. д.) к данным, а не перемещать данные в процессор.

Распределенная гипермедийная архитектура имееть только три основных свойства: 1) отрисовка данных в месте их хранения и отправка получателю изображений фиксированного формата; 2) инкапсуляция данных с помощью рендер движка и отправка обоих получателю; 3) отправка raw данных получателю вместе с метаданными, описывающими тип данных, чтобы получатель мог выбрать свой собственный движок рендеринга.

Каждой свойство имеет как преимущества, так и недостатки. Первое свойство, традиционно клиент-серверного стиля, позволяет всей информации о настоящей природе данных оставаться скрытой внутри отправителя, упрощая реализацию клиента и предотвращая неточные суждения о структуре данных. Однако, оно также серьезно ограничивает возможности получателя и накладывает большую часть нагрузки на отправителя, что может привести к проблемам расширяемости. Второе свойство, стиля мобильного объекта, предоставляет сокрытие информации, позволяя особым образом обрабатывать данные с помощью уникального движка рендеринга, но ограничивает возможность получателя определить, чего нужно ожидать от движка рендеринга и может значительно увеличить объем передаваемых данных. Третье свойство позволяет отправителю оставаться простым и расширяемым, минимизируя передаваемые байты, но теряет преимущества сокрытия информации и обязывает отправителя и получателя понимать одинаковые типы данных.

REST предоставляет гибрид этих трех свойств, фокусируясь на совместном понимании типов данных с метаданными, но ограничивает объем раскрываемых для стандартизированного интерфейса данных. REST компоненты взаимодействую между собой путем передачи представления ресурса в формате, соответсвующем одному из развивающихся наборов стандартных типов данных, отобранных динамически на основе природы самого ресурса и возможностей или требований получателя. Представление будет скрываться за интерфейсом внезавимости от того, находится ли оно в том же формате, что и необработанный источник, или получено из него. Преимущества стиля мобильного объекта достигаются посредством отправки представления, состоящего из инструкций в стандартном формате данных инкапсулированного движка рендеринга (например, как в Java). Потому REST достигает разделения интересов клиент-серверного стиля, не мешая расширяемости системы, и позволяет скрывать информацию через основной интерфейс, чтобы обеспечить инкапсуляцию и эволюцию сервисов, и обеспечивает разнообразный набор функций через загружаемые движки.

Элементы данных REST обобщены в таблице 5-1.

Untitled

5.2.1.1 Ресурсы и идентификаторы ресурса

Ключевой асбтракцией информации в REST является ресурс. Любая информация, которая может быть названа, может являться ресурсом: документ или изображение, временный сервис (например, "погода в Лос Анджелес на сегодня"), коллекция других ресурсов, невиртуальный объект (например, человек) и так далее. Другими словами, любой концепция, которая может быть целью гипертекстовой ссылки автора, должна попадать под определение ресурса. Ресурс - это концептуальное отображение набора сущностей, а не сущности, которая соответствует сопоставлению в любой конкретный момент времени.

Точнее, ресурс R является изменяющейся функцией M*R(t), которая за время *t mapsотображает набор сущностей или значений, который эквивалентны. Значения в наборе могут быть представлениями ресурсов и/или идентификаторами ресурсов. Ресурс может отображаться на пустой набор, который позволяет создавать ссылки на концепцию перед любой реализацией этой концепции - понятие, которое было чуждо большинству гипертекстовых систем до появления веба. Некоторые ресурсы являются статическими в том смысле, что при рассмотрении в любое время после их создания они всегда соттветствуют одному и тому же набору значений. Другие имеют высокую степень расхождений в занчениях с тчечением времени. Единственное, что требуется для статинчости ресурса - семантика, поскольку именно она отличает один ресурс от другого.

Например, "предпочтительной версией авторов" академической статьи является отображение, значение которого меняется со временем, тогда как "статьи, опубликованные в материалах конференции X" статичны. Это два разных ресурса, даже если они оба отображают одно и то же значение в определенный момент времени. Различие необходимо для того, чтобы оба ресурса можно было идентифицировать и ссылаться независимо. Аналогичным примером из разработки будет являться раздельный идентификатор файла исходного кода с управлением версиями при образении к "последней версии", "версии 1.2.7" или "версии, включенной в релиз Orange".

Это абстрактное определение ресурса включает ключевые особенности веб архитектуры. Первое: оно обеспечивает универсальность, охватывая множество источников информации без искусственного их различения по типу или реализации. Второе: оно допускает позднюю привязку ссылки к представлению, позволяя осуществлять согласование содержимого на основе характеристик запроса. И, наконец, позволяет автору ссылаться на концепцию, а не на какое-то единичное представление этой концепции, тем самым устраняя необходимость менять все существующие ссылки при изменении представления (при условии, что автор использовал правильный идентификатор).

REST использует идентификатор ерсурса для идентификации конкретного ресурса, участвующего во взаимодействии между компонентами. REST коннекторы предоставляют общий интерфейс для доступа к набору значений ресурса и манипулирования им независимо от того, как определена функция членства или от типа программного обеспечения, которое обрабатывает запрос. Инструмент, который назначил идентификатор ресурса, позволяющий ссылаться на ресурс, отвечает за поддержание семантической достоверности отображения с течением времени (т.е. гарантирует, что функция членства не изменяется).
Традиционные гипертекстовые системы, которые обычно действуют в закрытых или локальных окружениях, используеют уникальные идентификаторы узов или документов, которые изменяются сразу после изменения информации, полагаясь на серверы ссылок, чтобы поддреживать отдельно ссылки от контента. Поскольку централизованные серверы ссылок - это анафема для огромного масштаба и многопрофильных сетевых требований, вместо этого REST полагается на то, что автор выбирает идентификатор ресурса, который наилучшим образом соответствует природе идентифицируемой концепции. Естественно, качество идентификатора часто пропорционально сумме денег, потраченной на сохранение его валидности, что приводит к разрыву ссылок, когда эфемерная (или плохо поддерживаемая) информация перемещается или исчезает со временем.

5.2.1.2 Представления

REST компоненты выполняют действия с ресурсом, используя представление для захвата текущего или предполагаемого состояния этого ресурса и передачи этого представления между компонентами.. Представление - это последовательность байтов плюс метаданные представления для их описания. Другие часто используемые, но менее точные имена для представления включают: документ, файл, и экземпляр или сущность HTTP сообщения.

Представление состоит из данных, метаданных, описывающих данные, и, иногда, метаданных для описания метаданных (обычно для проверки целостности сообщения). Метаданные представлены в форме пар имя-значение, где имя соответствует стандарту, который определяет структуру и семантику значения. Сообщения ответов могут включать как метаданные представления, так и метаданные ресурса: информацию о ресурсе, которая не является специфичной для поставляемого представления.

Между компонентами управляющие данные определяют цель сообщения, например запрашиваемое действие или значение ответа. Он также используется для параметризации запросов и переопределения поведения некоторых дефолтных соединительных элементов. Например, поведение кэша может быть изменено управляющими данными, включенными в сообщение запроса или ответа.

В зависимости от данных управления сообщениями данное представление может указывать текущее состояние запрошенного ресурса, желаемое состояние запрошенного ресурса или значение некоторого другого ресурса, такого как представление входных данных в форме запроса клиента, или представление некоторого состояния ошибки для ответа. Например, удаленная разработка ресурса требует, чтобы автор отправлял представление на сервер, устанавливая таким образом значение для этого ресурса, которое может быть получено последующими запросами. Если набор значений ресурса в данный момент времени состоит из нескольких представлений, согласование контента может использоваться для выбора наилучшего представления для включения в данное сообщение.

Формат данных представления известен как медиа тип. Представление может быть включено в сообщение и обработано получателем в соответствии с контрольными данными сообщения и характером типа носителя. Некоторые типы мультимедиа предназначены для автоматической обработки, некоторые предназначены для просмотра пользователем, а некоторые способны на оба. Составные типы мультимедиа могут использоваться для включения нескольких представлений в одно сообщение.

Конструкция мультимедийного типа может напрямую влиять на воспринимаемую пользователем производительность распределенной гипермедиа-системы. Любые данные, которые должны быть получены до того, как получатель сможет начать рендеринг, увеличивают задержку взаимодействия. Формат данных, который помещает наиболее важную информацию рендеринга вперед, так что исходная информация может быть постепенно увеличена, пока остальная информация принимается, приводит к гораздо лучшей воспринимаемой пользователем производительности, чем формат данных, который должен быть полностью получен до рендеринг может начаться.

Например, веб-браузер, который может постепенно визуализировать большой HTML-документ во время его получения, обеспечивает значительно лучшую воспринимаемую пользователем производительность, чем та, которая ожидает, пока весь документ полностью не будет получен перед рендерингом, даже если производительность сети одинакова. Обратите внимание, что на возможность визуализации представления также может повлиять выбор контента. Если размеры динамически изменяемых таблиц и встроенных объектов должны быть определены до того, как они могут быть отображены, их появление в области просмотра страницы гипермедиа увеличит ее задержку.

5.2.2 Коннекторы

REST использует различные типы коннекторов, приведенные в таблице 5-2, для инкапсулирования доступа к ресурсам и передачи их представлений. Коннекторы представляют собой абстрактный интерфейс для взаимодействия компонентов, упрощая его четким разделением проблем и сокрытием базовой реализации ресурсов и механизма связи. Универсальность интерфейса также обеспечивает заменяемость: если пользователь имеет доступ к системе только с помощью абстрактного интерфейса, реализация омжет быть заменена без влияния на пользователей. Поскольку коннектор управляет сетевым взаимодействием для компонента, информация может быть доступна через несколько взаимодействий для улучшения эффективности и отзывчивости.

Untitled

Все REST взаимодействия не имею состояния. То есть, каждый запрос содержит всю необходимую информацию для того, чтобы коннектор понял запрос вне зависимости от любых запросов, которые могли предшествовать ему. Это ограничение выполняет четыре функции: 1) устраняет необходимость коннекторам сохранять состояние между запросами, что, тем самым, сокращает потребление физических ресурсов и улучшает расширяемость; 2) позволяет обрабатывать взаимодействия параллельно, не требуя, чтобы механизм обработки понимал семантику взаимодействия; 3) позволяет посреднику просматривать и понимать запрос изолированно, что может быть необходимо, если сервисы перестраиваются динамически; и 4) заставляет всю информацию, которая может влиять на переиспользуемость кэшированного ответа присутствовать в каждом запросе.

Интерфейс коннектора аналогичен процедурному вызову, но с несколькими важными различиями в передаче параметров и результатов. Входные параметры состоят из данных управления запросом, идентификатора указывающего на цель запроса ресурса и необязательного представления, выходные - из данных управления ответом, необязательных метаданных ресурса и необязательного представления. С абстрактной точки зрения вызов является синхронным, но оба вида параметров могут передаваться как потоки данных. Другими словами, обработка может вызываться перед тем, как значения параметров будут известны полностью, что позволяет избегать задержек пакетной обработки больших передач данных.

Основными типами коннектора является клиент и сервер. Существенная разница между этимти двумя в том, что клиент, отправляя запрос, инициирует взаимодействие, а сервер прослушивает соединения и отвечает на запросы. Компонент может содержать коннекторы как клиента, так и сервера.

Третий тип коннетора - коннектор кэша - может располагаться на интерфейсе клиента или сервера для сохранения кэшируемых ответов на текущие взаимодействия, чтобы их можно было повторно использовать для последующих запрошенных взаимодействий. Кэш может использоваться клиентом для избежания повторного сетевого взаимодействия, или сервером для избежания птовроного процесса генерации ответа, причем оба случая служат для уменьшения задержки взаимодействия. Кэш обычно реализуется в адресном пространстве соединителя, которые его использует.

Некоторые кэш коннекторы являются общими, что означает, что его кэшированные ответы могут использоваться в ответе клиенту, отличному от того, для которого ответ был получен первоначально. Такое совместное кэширование может быть эффективным для снижения влияния "flash crowds" на нагруженный сервер, особенно когда кэширование организовано иерархически для охвата больших групп пользователей, таких как пользователи внутренней сети компании, клиенты интернет-услуг, провайдера или университеты, разделяющие магистраль национальной сети. Однако, совместное кэширование также может приводить к ошибкам, если кэшированный ответ не совпадает с тем, что было бы получено новым запросом. REST пытается сбалансировать стремление к прозрачности в поведении кэша со стремлением к эффективнмоу использованию сети, а не предполагать, что абсолютная рпозрачность требуется всегда.

Кэш может определять кэшируемость запроса, поскольку интерфейс является общим, а не специфическим для каждого ресурса. По умолчанию, ответ на запрос поиска кэшируется, а ответы на другие запросы нет. Если какая-либо форма аутентификации пользователя является частью запроса, или если ответ указывает, что он не должен использоваться совместно, тогда ответ может быть кэширован только в кэш общего пользования. Компонент может переопределять эти значения по умолчанию, включив управляющие данные которые помечают взаимодействие как кэшируемое, не кэшируемое или кэшируемое только в течение ограниченного времени.

Средство распознавания преобразует частичные или полные идентификаторы ресурса в информацию о сетевом аддресе, необходимую для устноавления межкомпонентного соединения. например, большинство URI включают в себя имя хоста DNS в качетсве механизма идентификации полномочий ресурса по его именованию. Чтобы инициировать запрос, веб браузер извлечет имя хоста из URI и использует распознаватель DNS для получения адреса интернет-протокола. Другой пример: некоторые схемы идентификации (например, URN) требуют, чтобы посредник преобразовывал постоянный идентификатор в более переходный адрес для доступа к идентифицированному ресурсу. Использование одного или нескольких промежуточных распознавателей может увеличить долговечность ссылок на ресурсы за счет косвенного обращения, хотя это увеличить задержку запроса.

Последним типом коннектора является туннель, который просто передает взаимодействия через границу соединения, такую как межсетевой экран или сетевой шлюз более низкого уровня. Единственная причина, по которой он моделируется как часть REST и не абстрагируется как часть сетевой инфраструктуры, в том, что некоторые REST компоненты из поведения активного компонента на поведение туннеля могут переключаться динамически. Основным примером является HTTP прокси, который переключается на туннель в ответ на метод CONNECT запроса, что позволяетс его клиенту напрямую связываться с удаленным сервером используя другом протокол, такой как TLS, который не допускает прокси. Такой туннель исчезает, когда оба конца соединения прекращают связь.

5.2.3 Компоненты

REST компнонеты, выведенные в таблице 5-3, типизируются на основе принимаемых ими ролей в событиях приложения.

Untitled

User agent использует клиентский коннектор для инициирования запроса и становится окончательным его получателем. Основной пример - веб браузер, который предоставляет доступ к информационным сервисам и отрисовывает ответы сервисов в соответсвии с потребностями приложения.

Origin server использует серверный коннектор для управления пространством имен для запрашиваемого ресурса. Является окончательным источником для представления своих ресурсов и должен быть окончательным получаетел любого запроса, если тот требует изменения значений своих ресурсов. Каждый origin server предоставляет общий интерфейс для своих сервисов в виде иерархии ресурсов. Детали реализации ресурса сокрыты за интерфейсом.

Для пересылки запросов и ответов промежуточные компоненты ведут себя и как клиент, и как сервер. Компонент proxy является посредником, выбранным клиентом для обеспечения интерфейса инкапсуляции для своих сервисов, трансляции данных, повышения производительности и защиты безопасности. Шлюзовый (a.k.a., reverse proxy) компонент - посредник, навязанный сетевым или исходным сервером для обеспечения инкапсуляции интерфейса других служб, для перевода данных, повышения производительности или обеспечения безопасности. Заметьте, что разница между proxy и шлюзом в том, что клиенту нужно явно определить, когда ему нужно использовать proxy.

5.3 Архитектурные представления REST

Теперь, когда у нас есть понимание архитектурных элементов REST в отдельности, мы можем использовать архитектурные представления, чтобы описать, как элементы работают вместе, чтобы сформировать архитектуру. Три типа представлений - процесс, коннектор и данные - полезны для освещения принципов проектирования REST.

5.3.1 Представление процесса

Процессное представление архитектуры в первую очередь эффективно для выявления взаимосвязей взаимодействия между компонентами, показывая путь данных, когда они проходят через систему. Процессное представление архитектуры в первую очередь эффективно для выявления взаимосвязей взаимодействия между компонентами, показывая путь данных, когда они проходят через систему. На изображении 5-10 приведен пример представления процесса из архитектуры на основе REST в конкретном случае во время обработки трех параллельных запросов.

Разделение интересов клиента и сервера REST упрощает реализацию компонентов, снижает сложность семантики коннекткоров, повышает эффективность настройки производительности и масштабируемость компонентов чистого сервера. Многоуровневые системные ограничения позволяют вводить посредников - прокси, шлюзы и межсетевые экраны - в различных точках обмена данными, не изменяя интерфейсы между компонентами, что позволяет им помогать в преобразовании обмена данными или повышать производительность посредством крупномасштабного общего кэширования. REST позволяет выполнять промежуточную обработку, ограничивая сообщения для самоописания: взаимодействие не требует состояния между запросами, стандартные методы и типы мультимедиа используются для указания семантики и обмена информацией, а ответы явно указывают на кешируемость.

Поскольку компоненты подключаются динамически, их расположение и функции для конкретного действия приложения имеют характеристики, аналогичные стилю конвейера (pipe) и фильтра. Хотя компоненты REST обмениваются данными через двунаправленные потоки, обработка каждого направления независима и поэтому восприимчива к преобразователям потока (фильтрам). Общий интерфейс соединителя позволяет размещать компоненты в потоке на основе свойств каждого запроса или ответа.

Сервисы могут быть реализованы с использованием сложной иерархии посредников и нескольких серверов распределенного происхождения. Природа REST без сохранения состояния позволяет каждому взаимодействию быть независимым от других, устраняя необходимость в понимании общей топологии компонентов, невыполнимую задачу для архитектуры масштаба веба и позволяя компонентам выступать в качестве пунктов назначения или посредников, определяемых динамически по цели каждого запроса. Коннекторы должны знать о существовании друг друга только во время их взаимодействия, хотя они могут кэшировать существование и возможности других компонентов по соображениям производительности.

5.3.2 Представление коннектора

Представление архитектуры соединителя концентрируется на механике связи между компонентами. Для архитектуры на основе REST нас особенно интересуют ограничения, которые определяют общий интерфейс ресурсов.

Клиентские коннекторы проверяют идентификатор ресурса, чтобы выбрать подходящий механизм связи для каждого запроса. Например, клиент может быть сконфигурирован для соединения с конкретным прокси-компонентом, возможно, таким, который действует как фильтр аннотаций, когда идентификатор указывает, что это локальный ресурс. Аналогично, клиент может быть настроен на отклонение запросов для некоторого подмножества идентификаторов.

REST не ограничивает связь конкретным протоколом, но ограничивает интерфейс между компонентами и, следовательно, дополняет область предположений о взаимодействии и реализации, которые могли бы быть сделаны между компонентами. Например, основным протоколом передачи в Интернете является HTTP, но в архитектуру также входит беспрепятственный доступ к ресурсам, которые создаются на уже существующих сетевых серверах, включая FTP, Gopher и WAIS. Взаимодействие с этими службами ограничено семантикой коннектора REST. Это ограничение жертвует некоторыми из преимуществ других архитектур, таких как взаимодействие с состоянием протокола обратной связи по релевантности, такого как WAIS, чтобы сохранить преимущества единого универсального интерфейса для семантики коннектора. В свою очередь, общий интерфейс позволяет получить доступ к множеству сервисов через один прокси. Если приложению требуются дополнительные возможности другой архитектуры, оно может реализовать и вызвать эти возможности как отдельную систему, работающую параллельно, подобно тому, как веб-архитектура взаимодействует с ресурсами "telnet" и "mailto".

5.3.3 Представление данных

Представление данных раскрывает состояние приложения при прохождении информации через компоненты. Поскольку REST специально нацелен на распределенные информационные системы, он рассматривает приложение как связную структуру информации и альтернатив управления, с помощью которых пользователь может выполнять желаемую задачу. Например, поиск слова в онлайн-словаре - это одно из приложений, как, например, путешествие по виртуальному музею или просмотр набора заметок для подготовки к экзамену. Каждое приложение определяет цели для базовой системы, по которым можно измерить производительность системы.

Взаимодействие компонентов происходит в форме сообщений динамического размера. Сообщения малого или среднего размера используются для семантики управления, но основная часть работы приложения выполняется через сообщения большого размера, содержащие полное представление ресурса. Наиболее частой формой семантики запроса является извлечение представления ресурса (например, метода «GET» в HTTP), который часто можно кэшировать для последующего повторного использования.

REST концентрирует все состояние управления в представлениях, полученных в ответ на взаимодействия. Цель состоит в том, чтобы повысить расширяемость сервера, устраняя необходимость для сервера поддерживать осведомленность о состоянии клиента за пределами текущего запроса. Поэтому состояние приложения определяется его ожидающими запросами, топологией подключенных компонентов (некоторые из которых могут быть фильтрацией буферизованных данных), активными запросами на этих коннекторах, потоком данных представлений в ответ на эти запросы и обработкой этих представления, как они получены агентом пользователя.

Приложение достигает устойчивого состояния, когда у него нет невыполненных запросов; то есть он не имеет ожидающих запросов, и все ответы на его текущий набор запросов были полностью получены или получены до такой степени, что их можно рассматривать как поток данных представления. Для приложения браузера это состояние соответствует «веб-странице», включающей первичное представление и вспомогательные представления, такие как встроенные изображения, встроенные апплеты и таблицы стилей. Важность стационарных состояний приложений проявляется в их влиянии как на воспринимаемую пользователем производительность, так и на интенсивность трафика сетевых запросов.

Воспринимаемая пользователем производительность приложения браузера определяется задержкой между установившимися состояниями: периодом времени между выбором гипермедиа-ссылки на одной веб-странице и моментом представления полезной информации для следующей веб-страницы. Поэтому оптимизация производительности браузера сосредоточена на уменьшении этой задержки связи.

Поскольку основанные на REST архитектуры обмениваются данными главным образом посредством передачи представлений ресурсов, на задержку могут влиять как структура протоколов связи, так и конструкция форматов данных представления. Возможность постепенной визуализации данных ответа по мере их получения определяется конструкцией типа носителя и доступностью информации макета (визуальные размеры встроенных объектов) в каждом представлении.

Важное наблюдение: наиболее эффективный сетевой запрос - это тот, который не использует сеть. Другими словами, возможность многократного использования кэшированного ответа приводит к значительному улучшению производительности приложения. Хотя использование кэша добавляет некоторую задержку к каждому отдельному запросу из-за накладных расходов на поиск, средняя задержка запроса значительно уменьшается, когда даже небольшой процент запросов приводит к используемым обращениям к кешу.

Следующее состояние управления приложением находится в представлении первого запрошенного ресурса, поэтому получение этого первого представления является приоритетом. Поэтому взаимодействие REST улучшается с помощью протоколов, которые «сначала отвечают, а потом думают». Другими словами, протокол, который требует множественных взаимодействий для каждого действия пользователя, для того, чтобы выполнить такие вещи, как согласование возможностей функции перед отправкой ответа на контент, будет значительно медленнее, чем протокол, который сначала отправляет то, что наиболее вероятно будет оптимальным, а затем обеспечивает список альтернатив, которые клиент может получить, если первый ответ неудовлетворителен.

Состояние приложения контролируется и сохраняется пользовательским агентом и может состоять из представлений от нескольких серверов. В дополнение к освобождению сервера от проблем расширяемости сохранения состояния, это позволяет пользователю напрямую манипулировать состоянием (например, историей веб-браузера), предвидеть изменения в этом состоянии (например, карты ссылок и предварительную выборку представлений) и выполнять переход из одного приложения в другое (например, закладки и диалоги ввода URI).

Следовательно, модельное приложение представляет собой механизм, который перемещается из одного состояния в другое путем изучения и выбора среди альтернативных переходов состояний в текущем наборе представлений. Не удивительно, что это точно соответствует пользовательскому интерфейсу гипермедиа браузера. Однако стиль не предполагает, что все приложения являются браузерами. Фактически, детали приложения скрыты от сервера с помощью универсального интерфейса коннектора, и, таким образом, пользовательский агент может в равной степени быть автоматическим роботом, выполняющим поиск информации для службы индексирования, личным агентом, который ищет данные, которые соответствуют определенным критериям, или обслуживанием. Паук занят патрулированием информации на предмет неработающих ссылок или измененного контента.

разбираемся с байткодом v8 [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:36 +0000

Вольный перевод статьи Franziska Hinkelmann "Understanding V8’s Bytecode"

Разбираемся с байткодом V8

V8 - это опенсорсный движок для JavaScript, разработанный Google. Chrome, Node.js и многие другие приложения используют V8. В этой статье будет предложено объяснение формата байткода V8, который, на самом деле, станет очень простым для чтения, как только вы поймете некоторые основные концепты.

Ignition, lift-off! Интерпретатор Ignition является частью пайплайна компилятора с 2016-го года.

Когда V8 компилирует JavaScript код, парсер генерирует абстрактное синтаксическое дерево. Синтаксическое дерево - это древовидное представление синтаксической структуры JavaScript кода, из которого интерпретатор Ignition генерирует байткод. TurboFan - это оптимизирующий компилятор, который берет байткод и генерирует из него оптимизированный машинный код.

Пайплайн компилятора V8

Если хотите узнать, для чего нам нужно именно два режима выполнения, можете посмотреть мое видео с конференции JSConfEU:

video: https://www.youtube.com/watch?v=p-iiEDtpy6I&feature=emb_logo

Bytecode является абстракцией машинного кода. Компилировать байткод в машинный код будет проще, если байткод был спроектирован с одинаковой вычислительной моделью, что и физический CPU. Поэтому интерпретаторы обычно являются регистровыми или стэковыми машинами. Ignition - регистровая машина с аккумулятором (регистром процессора).

Байткоды V8 можно рассматривать как маленькие строительные блоки, которые выстраивают любую JavaScript функциональность, когда складываются вместе. V8 имеет несколько сотен байткодов. Есть байткоды для операций, вроде Add и TypeOf, или для загрузки свойств, вроде LdaNamedProperty. V8 также имеет несколько специфичных байткодов, вроде CreateObjectLiteral и SuspendGenerator. Головной файл bytecodes.h определяет полный их список.

Каждый bytecode определяет входные и выходные данные как операнды регистра. Ignition использует геристры r0, r1, r2, ... и аккумулятор, который также используют почти все байткоды. Он похож на обычный регистр, но байткоды его не определяют его точно. Например, Add r1 добавляет значение регистра r1 к значению в аккумуляторе, что позволяет сохранять память и хранить байткоды в более коротком виде.

Множество байткодов начинается с Lda или Sta. a в выражении Ld**a** и St**a** обозначает aккумулятор. Например, LdaSmi [42] подгружает маленькое целое число (Small Integer - Smi) 42 в регистр аккумулятора. Star r0 будет хранить текущее значение регистра r0.

Пора взглянуть на байткод реальной функции.

function incrementX(obj) {
  return 1 + obj.x;
}

incrementX({x: 42});  // Компилятор V8 ленив. Если вы не запустите функцию - он ее не интерпретирует.

Если вы хотите посмотреть на байткод V8 в JavaScript коде, то исполните команду с флагом --print-bytecode (для D8 и Node.js версии 8.3 и выше). Для Chrome вам нужно запустить его из командной строки с флагом --js-flags="--print-bytecode", см. Запуск Chromium с флагами.

$ node --print-bytecode incrementX.js
...
[generating bytecode for function: incrementX]
Parameter count 2
Frame size 8
  12 E> 0x2ddf8802cf6e @    StackCheck
  19 S> 0x2ddf8802cf6f @    LdaSmi [1]
        0x2ddf8802cf71 @    Star r0
  34 E> 0x2ddf8802cf73 @    LdaNamedProperty a0, [0], [4]
  28 E> 0x2ddf8802cf77 @    Add r0, [6]
  36 S> 0x2ddf8802cf7a @    Return
Constant pool (size = 1)
0x2ddf8802cf21: [FixedArray] in OldSpace
 - map = 0x2ddfb2d02309 <Map(HOLEY_ELEMENTS)>
 - length: 1
           0: 0x2ddf8db91611 <String[1]: x>
Handler Table (size = 16)

Большую часть вывода можно игнорировать и фокусироваться только на самих байткодах. Ниже описано шаг за шагом, что значит каждый байткод.

LdaSmi [1]

LdaSmi [1] загружает постоянное значение 1 в аккумулятор.

Star r0

Далее, Star r0 в регистре r0 хранит значение, которое на момент находится в аккумуляторе (1).

`LdaNamedProperty a0, [0], [4]`

LdaNamedProperty загружает именованное свойство a0 в аккумулятор. ai ссылается на i-ый аргумент incrementX(). В этом примере мы ищем именованное свойство в a0, первый аргумент incrementX(). Имя определяется константой 0. LdaNamedProperty использует 0 для нахождения имени в отдельной таблице:

- length: 1
           0: 0x2ddf8db91611 <String[1]: x>

Here, 0 отображает значение x, потому этот байткод загружает obj.x.

Для чего используется операнд со значением 4? Это индекс так называемого вектора обратной связи функции incrementX(), которые содержит нужную для оптимизаций производительности рантайм информацию.

Теперь регистры выглядят так:

Add r0, [6]

Последняя инструкция добавляет r0 в аккумулятор, возвращая в результате 43. 6 - это еще один индекс вектора обратной связи.

Return

Return возвращает значение аккумулятора. Это конец функции incrementX(). Вызывающий функцию incrementX() операнд получает значение 43 из аккумулятора и может начать работать с ним.

На первый взгляд, байткод V8 может показаться какой-то загадкой, особенно со всей остальной информацией в выводе. Но как только вы поймете что Ignition это регистровая машина с аккумулятором регистра, вы сможете понять за что отвечает большинство байткодов.

Примечание: в статье описывается байткод V8 версии 6.2, Chrome версии 62 и Node версии 9. Мы постоянно работаем над улучшением потребления памяти и производительности V8, потому детали в других версиях могут отличаться.

как начать just-in-time-ить [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:33 +0000

Вольный перевод статьи Fedor Indutny "How to start JIT-ting"

Как начать Just-In-Time-ить

Предпосылки

Большинство разработчиков что-то слышало об JIT компиляторах и как они могут замедлять интерпретируемые языки в сравнении с нативным кодом. Однако, не так много их них понимает как именно эта JIT штука работает, и еще меньше из них писали свои собственные компиляторы.

Как мне кажется, хотя бы базовые знания о внутренностях компилятора могут мощно прокачать понимание запускаемого обеспечением кода.

В этой статье мы посетим несколько вершин на JIT-острове, и возможно даже реализуем компилятор сами!

С чего начнем

Зная основы компилятора, мы можем вв что каждый компилятор трансформирует входные данные какого-то формата (обычно, исходный код) в выходные такого же или другого формата (обычно, в машинный код). JIT комплияторы не исключение.

Что делает их исключительными, так это то, что они запускаются не раньше времени (как gcc, clang и другие), а Just-In-Time (вовремя) (т.е. прямо перед выполнением выходных данных комплиятора).

чтобы начать разрабатывать наш собственный JIT компилятор, понадобится выбрать язык для входных данных. Принимая во внимание ТОП ЯЗЫКОВ 2013 ГОДА НА GITHUB, JavaScript выглядит подходяще для реализации некоторого ограниченного подмножества с упрощенной семантикой. Более того, мы реализуем JIT компилятор на самом JavaScript. Это можно назвать МЕТА-МЕТА!

Абстрактное Синтаксическое Дерево (AST)

На вход наш компилятор будет принимать JavaScript и возвращать (и немедленно выполнять) машинный код для очень популярной X64 платформы. Но, посокльку люддям удобнее работать с текстовым представлением, разработчики компиляторов обычно стремятся создать несколько Промежуточных Представлений (Intermediate Representations) перед генерацией окончательного машинного кода.

Поскольку мы пишем упрощенную версию, одного промежуточного представления будет достаточно, и для этого я выбрал представление в виде Абстрактное Синтаксическое Дерево (Abstract Syntax Tree).

Получить AST из JavaScript кода достаточно просто и мы можем выбрать несколько (из десятков) библиотек вроде esprima, uglify-js и т.д. . Чтобы не отходит далеко от туториала, я порекомендую вам выбрать esprima. Он имеет неплохой и четко определенный формат выходных данных.

Например, такой код obj.method(42) создаст (с помощью esprima.parse("...")) дерево следующего вида:

{ type: 'Program',
  body:
   [ { type: 'ExpressionStatement',
       expression:
        { type: 'CallExpression',
          callee:
           { type: 'MemberExpression',
             computed: false,
             object: { type: 'Identifier', name: 'obj' },
             property: { type: 'Identifier', name: 'method' } },
          arguments: [ { type: 'Literal', value: 42 } ] } } ] }

Машинный код

Давайте обобщим: у нас есть исходный код (check), его Абстрактное Синтаксическое Дерево (check), осталось только получить машинный код.

Если вы уже знакомы с assembly то можете пропустить эту главу поскольку она содержит только базовое введение в тему. ОДнако, если нет, последующая глава, без этих основ, может показаться вам сложной для понимания. Потому оставайтесь здесь, много времени не займет!

Язык Assembly - это ближайшее текстовое представление бинарного кода который понимает и(или) может запустить ваш CPU. Учитывая, что процессоры выполнябт код читая и запускаю иснтрукции по одной, может показаться логичным, что одна строка asse,bly программы представляет собой одну инструкцию:

mov rax, 1    ; Положить 1 в регистр `rax`
mov rbx, 2    ; Положить 2 в регистр `rbx`
add rax, rbx  ; Вычислить сумму `rax` и `rbx` и положить ее в регистр `rax`

Выходными данными этой прграммы будет являться 3 (при условии, что вы получите их из rax регистра). И, как вы уже наверно догадались, программа будет ложить данные в CPU слоты (регистры) и просить CPU вычислить их сумму.

Обычно процессоры имеют достаточное количество регистров для хранения результата промежуточных операций, но в некоторых случаях вам понадобится хранить/загружать данные из памяти кмопьютера:

mov rax, 1
mov [rbp-8], rbx  ; Сохранить rbx регистр в слот стека
mov rbx, 2
add rax, rbx
mov rbx, [rbp-8]  ; Восстановить rbx регистр из слота стека

Регистры имеют имена, слоты памяти имеют адреса. Эти ардеа обычно используют [...] синтаксис. Например, [rbp-8] означает: возьми значение регистра rbp , вычти из него 8, и достучись до слота памяти, используя значение результата в качестве адреса.

Как вы можете видеть мы используем rbp регистр. rbp обычно содержит адреса по которым переменные из стека (т.е. переменные, которые хранятся в текущем процедурной стеке) запускаются; 8 это размер rbx регистра (и всех остальынх регистров, название которые начинается на r), и поскольку стек растет снизу вверх, нам нужно вычесть его из rbp чтобы получить адрес свободного слота.

Есть много нюансов в программировании на низком уровне и к сожалению я не собираюсь обо всех них здесь рассказывать. Также имейте ввиду что я предоставляю очень поверхностное описание и то что происходит здесь на самом деле может быть гораздо более сложным.

Понятий поясненных выше должны быть достаточно чтобы приступить к генерации кода.

Генерация кода

Реализовать полностью JavaScript будет довольно сложно, потому сейчас мы реализуем только упрощенную версию арифметического движка.

Лучшим и простейшим способом сделать это будет с помощью прохода по AST с помощью поиска в глубину, генерирую машинный код для каждого узла. Вы можете подумать как можно генерирвоать машинный код для такого memory-safe языка как JavaScript. Здесь я представлю вам jit.js.

Это node.js модуль (и C++ аддон, по сути) способный генерировать и выполнять машинны код используя assembly-подобный JavaScript синтаксис:

var jit = require('jit.js');

var fn = jit.compile(function() {
  this.Proc(function() {
    this.mov('rax', 42);
    this.Return();
  });
});
console.log(fn());  // 42

Давайте уже напишем это

Таким образом нам осталось сделать только одну вещь - модуль для прохода по AST, сгенерированному с помозью esprima. К счастью, учитывая его структуру и наш минималистичный дизайн компилятора это должно быть довольно просто.

Мы внедрим поддержку:

Числовых литералов ({ type: 'Literal', value: 123 })
Бинарных выражений с операторами: +, -, *, /, % ({ type: 'BinaryExpression', operator: '+', left: ... , right: .... })
Унарных выражений с оператором - ({ type: 'UnaryExpression', operator: '-', argument: ... })

Все эти операции выполняются на целых числах, потому не ожидайте что они сработают со значениями вроде 0.5, 0.66666 и т.д. .

Во время обработки выражения мы будем посещать каждый поддерживаемый узел AST и генерировать код, который вернет результат в rax регистр. Звучить легко, да? Здесь есть одно правило: мы должны сохранять все остальные регистры чистыми после выхода из узла дерева. Другими словами, это значит что мы должны сохранять все использованные регистры и восстанавливать их состояние после того как они не нужны. К счастью, CPU имеет две волшебные операцииpush и pop которые помогут нам с этой задачей.

Таким получится код (с комментариями):

var jit = require('jit.js'),
    esprima = require('esprima'),
    assert = require('assert');

var ast = esprima.parse(process.argv[2]);

// Compile
var fn = jit.compile(function() {
  // Создаем шаблон для входных данных по умолчанию
  this.Proc(function() {
    visit.call(this, ast);

    // Результат должен быть в 'rax'

    // Создаем шаблон для выходных данных
    this.Return();
  });
});

// Выполнение
console.log(fn());

function visit(ast) {
  if (ast.type === 'Program')
    visitProgram.call(this, ast);
  else if (ast.type === 'Literal')
    visitLiteral.call(this, ast);
  else if (ast.type === 'UnaryExpression')
    visitUnary.call(this, ast);
  else if (ast.type === 'BinaryExpression')
    visitBinary.call(this, ast);
  else
    throw new Error('Неизвестный AST узел: ' + ast.type);
}

function visitProgram(ast) {
  assert.equal(ast.body.length,
               1,
               'Поддерживается только один оператор');
  assert.equal(ast.body[0].type, 'ExpressionStatement');
  visit.call(this, ast.body[0].expression);
}

function visitLiteral(ast) {
  assert.equal(typeof ast.value, 'number');
  assert.equal(ast.value | 0,
               ast.value,
               'Поддерживаются только целочисленные значения');

  this.mov('rax', ast.value);
}

function visitBinary(ast) {
  // Сохраняем 'rbx' после того, как вышли из AST узла
  this.push('rbx');

  // Посещаем правую стороно выражения
  visit.call(this, ast.right);

  // Перемещаем в 'rbx'
  this.mov('rbx', 'rax');

  // Посещаем левую сторну выражения (результат в 'rax')
  visit.call(this, ast.left);

  //
  // Обобщяя, левая сторона хранится в 'rax', правая - в 'rbx'
  //

  // Выполняем бинарную операцию
  if (ast.operator === '+') {
    this.add('rax', 'rbx');
  } else if (ast.operator === '-') {
    this.sub('rax', 'rbx');
  } else if (ast.operator === '*') {
    // Умножение со знаком
    // rax = rax * rbx
    this.imul('rbx');
  } else if (ast.operator === '/') {
    // Сохраняем 'rdx'
    this.push('rdx');

    // idiv выполняет деление rdx:rax на rbx, следовательно, нам нужно очистить rdx
    // перед запуском
    this.xor('rdx', 'rdx');

    // Деление со знаком, rax = rax / rbx
    this.idiv('rbx');

    // Восстанавливаем 'rdx'
    this.pop('rdx');
  } else if (ast.operator === '%') {
    // Сохраняем 'rdx'
    this.push('rdx');

    // Готовимся выполнить idiv
    this.xor('rdx', 'rdx');
    this.idiv('rbx');

    // idiv помещает остаток в 'rdx'
    this.mov('rax', 'rdx');

    // Восстанавливаем 'rdx'
    this.pop('rdx');
  } else {
    throw new Error('Неподдерживаемый бинарный оператор: ' + ast.operator);
  }

  // Восстанавливаем 'rbx'
  this.pop('rbx');

  // Результат в 'rax'
}

function visitUnary(ast) {
  // Посещаем аргумент и складываем результат в 'rax'
  visit.call(this, ast.argument);

  if (ast.operator === '-') {
    // Делаем аргумент отрицательным
    this.neg('rax');
  } else {
    throw new Error('Неподдерживаемый унарный оператор: ' + ast.operator);
  }
}

Вы можете попробоать сами склонировав исходный код с github, запустив npm install и вуаля!

$ node ./main.js '1 + 2 * 3'
7

назначаем числа [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:31 +0000

Вольный перевод статьи Fedor Indutny "Allocating numbers"

Назначаем числа

Цели

В прошлой статье мы создали JIT компилятор, поддерживающий очень ограниченное количесвто подномежств JavaScript: целые числа, бинарные математические операции операторы (+, -, *, /), и унарный оператор -. В этот раз мы расширим его добавлением поддержки чисел с плавающей точкой, а, чтобы процесс стал живее и веселее, мы будем выделять и хранить эти числа в куче.

Поскольку мы внедряем функциональность небольшими шагами, на этом этапе наша куча не будет иметь сборщика мусора и будет жить внутри чанка памяти фиксированного размера (скажи "ура" простоте!).

Stubs

Отталкиваясь от наших целей мы можем установить внутренние структуры для желаемых фич. По сути, нам понадобится процедура выделения памяти, которая генерирует и возвращает подходящий нашим целям участок памяти.

Такое выделение может быть сгенерировано для каждого узла AST с помощью серий встроенных assembly инструкций, которые великолепно работают и, что более важно, невероятно быстро исполняются для коротких операций. Но из-за относительного большого размера кодовой базы это процедуры, финальный вывод в виде машинного кода может не поместиться в кэше CPU, вызывая потенциальные проблемы с производительностью всей системы.

Как правило, это считается плохой практикой. Более лучшим подходом будет будет параметризация таких блоков кода в общие процедуры, называемые stubs (я взял это название из кода v8 и, похоже, они имеют такое же название и в других VM). Для еще большей оптимизации эти процедуры можно компилировать лениво, т.е. мы не должны компилировать участки, которые не используются генерируемым кодом. Эта техника хорошо сказывается на времени компиляции и размере выполняемого кода (и, соответснвенно, кэше CPU).

К счастью, jit.js позволяет достаточно легко генерировать stubs:

var stubs = jit.stubs();

stubs.define('Allocate', function() {
  // Наш код здесь
  // ....

  // Возвращаемся к месту вызова
  this.Return();
});

Просто, не так ли? Чтобы использовать это в нашем JIT компиляторе нам нужно передать его в аргументы:

jit.compile(function() {
  // Пояснение:
  // Прочитать адрес стаба 'Allocate' в регистре 'rax' и
  // вызвать его.
  this.stub('rax', 'Allocate');

  this.Return();
}, { stubs: stubs });

Как я заметил выше, сгенерированы и переиспользованы будут только те стабы, которые исподьзовались во вермя процесса компиляции.

Куча

Теперь мы можем перейти к выделению памяти. Но сначала давайте взнглянем на структуру и организацию кучи.

Куча - это место, где JavaScript (и многие другие) VM создает и хранит обхекты (обычно те которые не могут уместиться в регистрах CPU). Некоторые объекты кучи могут содержать ссылки на другие объекты (другими словами, могут ссылаться на них). Все живущие объекты и их ссылки создают ориентированный граф начиная с так называех корней (который обычно являются глобальными переменными и указателями в стеке).

И хоть она обычно используется для VM, сборка мусора не обязательна для кучи. Многие виртуальные машины и языки выбирают неуправляемую память вместо того (C/C++ как пример). В таких случаях (как пользователь языка) будет необзодимо явно очищать неиспользуемые ресурсы чтобы не исчерпать память.

Но по очевидным причинам компилятор подмножеств JavaScript который мы реализуем должен поддерживать как управляемую память так и сборку мусора (что сделаем позже).

Есть тонны кнги котоыре могут дать вам продвинутое представление о распределении кучи и сборке мусора (я порекомендую The Garbage Collection Handbook) и и значительно много способов выделения и сборки памяти в куче.

Обычно вам понадобится выбрать между скоростью выделения и фрагментацией памяти. Но поскольку мы не углубляемся в тему я порекомендую остановиться на методе "bump allocation".

Bump allocation

bump allocation для фиксированных страниц работает следующим образом.

Взять чанк памяти фиксированного значения (страница)
Отдать последующие фрагменты в виде возвращаемого значение процедуры выделения.
Сжимая или перемещая живущие объекты в новый чанк памяти, запускать сборку мусора и очищать неиспользуемое пространство,когда кончается память, (заменяя ссылки на живущие обхекты).

Используя jit.js и стабы, эта процедура может выглядеть следующим образом:

// Создаем чанки памяти фиксированного размера
var page = new Buffer(1024);

// Устанавливаем указатели на начало и конец страницы
var offset = jit.ptr(page);
var end = jit.ptr(page, page.length);

stubs.define('Alloc', function() {

  // Сохраняем регистры 'rbx' и 'rcx'
  this.spill(['rbx', 'rcx'], function() {
    // Загружаем `offset`
    //
    // ПРИМЕЧАНИЕ: Мы будем использовать указатель для переменной `offset`, чтобы была вохможность
    // позже обновить ее
    this.mov('rax', this.ptr(offset));
    this.mov('rax', ['rax']);

    // Конец заргрузки
    //
    // ПРИМЕЧАНИЕ: То же самое относится и к концу страницы, но мы не обновляем его прямо сейчас
    this.mov('rbx', this.ptr(end));
    this.mov('rbx', ['rbx']);

    // Вычисляем новый `offset`
    this.mov('rcx', 'rax');

    this.add('rcx', 16);

    // Проверяем, не переполняется ли буффер фиксированного размера
    this.cmp('rcx', 'rbx');

    // this.j() выполняет условный переход к указанной метке.
    // 'g' означает 'greater'
    // 'overflow' - это имя метки, связанной ниже
    this.j('g', 'overflow');

    // Окей, может двигаться дальше и обновить offset
    this.mov('rbx', this.ptr(offset));
    this.mov(['rbx'], 'rcx');

    // Первый 64-х битный указатель зарезервирован для 'tag',
    // второй имеет значенеи `double`
    this.mov(['rax'], 1);

    // Возвращаем 'rax'
    this.Return();

    // Переполнение :(
    this.bind('overflow')

    // Вызываем javascript функцию!
    // ПРИМЕЧАНИЕ: Штука ниже очень прикольная, но я поясню ее позже
    this.runtime(function() {
      console.log('GC is needed, but not implemented');
    });

    // Краш
    this.int3();

    this.Return();
  });
});

Это все! Не совсем просто, но не так уж и сложно!

Эта процедура будет выдавать последующие куски страницы и даже помечать их (про это поговорим в одном из будующих постов. По сути, они используются определения разных типов объектов кучи. )!

Стоит отметить пару моментов:

jit.ptr(buf, offset) возвращает Buffer, содержащий указатель на данный buf с добавленным к нему offset.
this.spill() - это процедура для сохранения и восстановления регистров памяти (обычно называется spilling). Принимает список регистров и коллбэк. Эти регистры будут сохранены перед входом в коллбэк и восстановлены после выхода из него. ПРИМЕЧАНИЕ: ВОсстановленный код будет сгенерирован перед каждым this.Return().
this.mov(['rbx'], 'rcx') сохраняет регистр rcx в ячейку памяти, на которую указывает значение регистра rbx. ПРИМЕЧАНИЕ: offset также можно указать здесь: this.mov(['rbx', 8], 'rcx').
jit.js поддерживает ветвления примитивов: this.cmp(a, b), this.j(condition, labelName), this.j(labelName), this.bind(labelName).

Плавающая запятая

Теперь, когда у нас есть предположительно работающая процедура, давайте вспомним что должно храниться внутри чанков нашей кучи. Мы создали чанки со значением тега 8 байт и содержимым 8 байт. Этого достаточно чтобы хранить double (как C тип) числа с плавающей запятой.

Есть множество assembly инструкций для загрузки/хранения и работы с такими числами. Но заметьте что для работы с ними их нужно хранить в разных наборах регистров: xmm0, xmm1, ... xmm15. Хотя, 64-х битные числа с плавающей запятой могут храниться и в регистрах общего назначения: rax, rbx, ... Математические операции возможны только с набором регистров xmm. Ниже несколько инструкций которые присутстввуют в jit.js и могут быть полезными нашему компилятору:

movq('xmm', 'gp') или movq('gp', 'xmm') для перемещения 64-х битных значений из регистра общего назначения в xmm, или наоборот.
movsd('xmm', 'xmm') для перемещения значения из одного xmm к другому.
addsd, mulsd, subsd, divsd - сложение, умножение, вычитание, деление.
cvtsi2sd('xmm', 'gp'), cvts2si('gp', 'xmm') для концертации целых чисел в double, и наоборот.
roundsd('mode', 'xmm', 'xmm') для округления значения регистра src с помощью указанного режима mode (одного из: nearest, down, up, zero) и помещения результата в регистр dst.

Используя это священное знание, мы можем исправить наш код, чтобы он работал с числами с плавающей запятой (да, мы пока удалим целочисленную поддержку).:

// Compile
var fn = jit.compile(function() {
  // Создаем шаблон для входных данных по умолчанию
  this.Proc(function() {
    visit.call(this, ast);

    // Результат должен быть в 'rax'
    //
    // Создаем шаблон для выходных данных
    this.Return();
  });
}, { stubs: stubs });

// Выполнение
console.log(fn());

function visit(ast) {
  if (ast.type === 'Program')
    visitProgram.call(this, ast);
  else if (ast.type === 'Literal')
    visitLiteral.call(this, ast);
  else if (ast.type === 'UnaryExpression')
    visitUnary.call(this, ast);
  else if (ast.type === 'BinaryExpression')
    visitBinary.call(this, ast);
  else
    throw new Error('Неизвестный AST узел: ' + ast.type);
}

function visitProgram(ast) {
  assert.equal(ast.body.length,
               1,
               'Поддерживается только один оператор');
  assert.equal(ast.body[0].type, 'ExpressionStatement');

  // Конвертируем в целое число имеющийся в 'rax' указатель
  visit.call(this, ast.body[0].expression);

  // Получаем число с плавающей запятой из числа кучи
  this.movq('xmm1', ['rax', 8]);

  // Округляем до нуля
  this.roundsd('zero', 'xmm1', 'xmm1');

  // Конвертируем double в целое число
  this.cvtsd2si('rax', 'xmm1');
}

function visitLiteral(ast) {
  assert.equal(typeof ast.value, 'number');

  // Выделяем новое число кучи
  this.stub('rax', 'Alloc');

  // Сохраняем 'rbx' регистр
  this.spill('rbx', function() {
    this.loadDouble('rbx', ast.value);
    this.mov(['rax', 8], 'rbx');
  });
}

function visitBinary(ast) {
  // Сохраняем 'rbx' после того, как вышли из AST узла
  this.spill('rbx', function() {
    // Посещаем правую сторону выражения
    visit.call(this, ast.right);

    // Перемещаем в 'rbx'
    this.mov('rbx', 'rax');

    // Посещаем левую сторону выражения (результат в 'rax')
    visit.call(this, ast.left);

    //
    // Обобщяя, левая сторона хранится в 'rax', правая - в 'rbx'
    //

    // Загружаем их значения в double представлении
    this.movq('xmm1', ['rax', 8]);
    this.movq('xmm2', ['rbx', 8]);

    // Выполняем бинарную операцию
    if (ast.operator === '+') {
      this.addsd('xmm1', 'xmm2');
    } else if (ast.operator === '-') {
      this.subsd('xmm1', 'xmm2');
    } else if (ast.operator === '*') {
      this.mulsd('xmm1', 'xmm2');
    } else if (ast.operator === '/') {
      this.divsd('xmm1', 'xmm2');
    } else {
      throw new Error('Неподдерживаемый бинарный оператор: ' + ast.operator);
    }

    // Выделяем новое число и складываем в него значение
    this.stub('rax', 'Alloc');
    this.movq(['rax', 8], 'xmm1');
  });
}

function visitUnary(ast) {
  if (ast.operator === '-') {
    // Делаем аргумент отрицательным эмулируя бинарное выражение
    visit.call(this, {
      type: 'BinaryExpression',
      operator: '*',
      left: ast.argument,
      right: { type: 'Literal', value: -1 }
    })
  } else {
    throw new Error('Unsupported unary operator: ' + ast.operator);
  }
}

smi и double представления [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:28 +0000

Вольный перевод статьи Fedor Indutny "SMIs and Doubles"

SMI и Double представления

Цели

В прошлой статье мы реализовали простой распределитель памяти и научили наш компилятор работать с числами с плавающей запятой, храня их в выделенных объектах кучи. Однако числа с плавающей запятой не подходят для некоторых точных операций, а также, поскольку они хранятся в памяти, что требует дополнительной загрузки и сохранения памяти, что снижает производительность кода.

Обе проблемы можно решить с помощью поддержки целых чисел, как мы делали в первой статье, что значит что нам нужно внедрить поддержку обоих типов чисел в рантайме компилятора.

Отметки

Вспомним, что мы храним указатели и числа в виде 64-х битных регистров общего назначения (rax, rbx, ...). Главная проблема в том, что мы должны иметь возможность определить, полученный регистр (например, rax) имеет указатель на объект кучи или на само число (SMI).

Обычно для такого используется метод "tagging". Есть несколько способов реализовать отметки, включая: Nan-Boxing (описание находится в блоке Mozilla’s New JavaScript Value Representation) и Nun-Boxing. Нашему компилятору нужно будет просто зарезервировать один бит 64-х битного регистра и добавлять к нему 1, если значение является указателем, и 0, если значение является SMI (Small Integer).

Пример:

Заметьте что чотбы получить значение SMI нам потребуется сдвинуть его на один бит вправо (>> 1) и конвертировать целое число в SMI - сдвиг влево (<< 1). Использование нуля для отметки SMI очень окупается, поскольку нам не нужно размечать числа, чтобы выполнить сложение и вычитание.

Чтобы использовать отмеченные указатели нам нужно найти значение находящееся на один бит левее фактического, что достаточно легко реализовать:

// Предположим что отмеченный указатель находится в rbx
// И нам нужно загрузить его содержимое в rax
this.mov('rax', ['rbx', -1]);

И для удобства, пример непомеченных SMI:

// Непомеченный
this.shr('rax', 1);
// Помеченный
this.shl('rax', 1);

И одна из главных частей - проверка является ли значение указателем:

// Проверить, есть ли у'rax' последний бит
this.test('rax', 1);

// 'z' означает zero
// Перейти к метке, если `(rax & 1) == 0`
this.j('z', 'is-smi');

// 'nz' означает non-zero
// Перейти к метке, если `(rax & 1) != 0`
this.j('ne', 'is-heap-object-pointer');

Перерабатываем имеющийся код

С помощью кода из прошлого поста, мы наконец можем приступить к реализации всех новых штук.

В первую очередь, давайте добавим helper методы.

function untagSmi(reg) {
  this.shr(reg, 1);
};

function checkSmi(value, t, f) {
  // Если не были определены `true-` и `false-`
  // просто тестируем значение.
  if (!t && !f)
    return this.test(value, 1);

  // Вводим новую область видимости, чтобы иметь возможность использовать именованные метки
  this.labelScope(function() {
    // Тестируем значение
    this.test(value, 1);

    // Пропускаем SMI случай, если результат non-zero
    this.j('nz', 'non-smi');

    // Запускаем SMI случай
    t.call(this);

    // Переходим к общему концу
    this.j('end');

    // Запускаем Non-SMI случай
    this.bind('non-smi');
    f.call(this);

    // Общий конец
    this.bind('end');
  });
};

function heapOffset(reg, offset) {
  // ПРИМЕЧАНИЕ: 8 - это размер указателя x64 архитектуры.
  // Добавляем 1 к смещению, поскольку на первом месте
  // хранится тип объектов кучи.
  return [reg, 8 * ((offset | 0) + 1) - 1];
};

Мы можем включить эти методы в контекст jit.js, передав их как свойство helpers в API метод jit.compile():

var helpers = {
  untagSmi: untagSmi,
  checkSmi: checkSmi,
  heapOffset: heapOffset
};

jit.compile(function() {
  // Здесь мы можем использовать хелперы:
  this.untagSmi('rax');

  this.checkSmi('rbx', function() {
    // Здесь работаем со SMI
  }, function() {
    // Здесь работаем с указателями
  });

  this.mov(this.heapOffset('rbx', 0), 1);
}, { stubs: stubs, helpers: helpers });

Назначение

Сейчас нам нужно сделать чтобы наш стаб Alloc вовзращал помеченный указатель. Также мы используем возможность и немного улучшим его с помощью добавления аргументов tag и size:

stubs.define('Alloc', function(size, tag) {
  // Сохраняем регистры 'rbx' и 'rcx'
  this.spill(['rbx', 'rcx'], function() {
    // Загружаем `offset`
    //
    // ПРИМЕЧАНИЕ: Мы будем использовать указатель для переменной `offset`, чтобы была вохможность
    // позже обновить ее
    this.mov('rax', this.ptr(offset));
    this.mov('rax', ['rax']);

    // Конец загрузки
    //
    // ПРИМЕЧАНИЕ: То же самое относится и к концу страницы, но мы не обновляем его прямо сейчас
    this.mov('rbx', this.ptr(end));
    this.mov('rbx', ['rbx']);

    // Вычисляем новый `offset`
    this.mov('rcx', 'rax');

    // Добавляем размер тега и тела
    this.add('rcx', 8);
    this.add('rcx', size);

    // Проверяем, не переполняется ли буффер фиксированного размера
    this.cmp('rcx', 'rbx');

    // this.j() выполняет условный переход к указанной метке..
    // 'g' означает 'greater'
    // 'overflow' - это имя метки, связанной ниже
    this.j('g', 'overflow');

    // Окей, может двигаться дальше и обновить offset
    this.mov('rbx', this.ptr(offset));
    this.mov(['rbx'], 'rcx');

    // Первый 64-х битный указатель зарезервирован для 'tag',
    // второй имеет значение `double`
    this.mov('rcx', tag);
    this.mov(['rax'], 'rcx');

    // !!!!!!!!!!!!!!!!!!!
    // ! Указатель метки !
    // !!!!!!!!!!!!!!!!!!!
    this.or('rax', 1);

    // Возвращаем 'rax'
    this.Return();

    // Переполнение :(
    this.bind('overflow')

    // Вызываем javascript функцию!
    // ПРИМЕЧАНИЕ: Штука ниже очень прикольная, но я поясню ее позже
    this.runtime(function() {
      console.log('GC is needed, but not implemented');
    });

    // Краш
    this.int3();

    this.Return();
  });
});

Математические стабы

Также нам придется немного доработать математические операции для поддержки SMI и double значений, давайте пока разделим их и добавим код который обрабатывает double:

var operators = ['+', '-', '*', '/'];
var map = { '+': 'addsd', '-': 'subsd', '*': 'mulsd',
            '/': 'divsd' };

// Определяем `Binary+`, `Binary-`, `Binary*` и `Binary/` стабы
operators.forEach(function(operator) {
  stubs.define('Binary' + operator, function(left, right) {
    // Сохраняем 'rbx' и 'rcx'
    this.spill(['rbx', 'rcx'], function() {
      // Загружаем аргументы для rax и rbx
      this.mov('rax', left);
      this.mov('rbx', right);

      // Конвертируем оба числа в double
      [['rax', 'xmm1'], ['rbx', 'xmm2']].forEach(function(regs) {
        var nonSmi = this.label();
        var done = this.label();

        this.checkSmi(regs[0]);
        this.j('nz', nonSmi);

        // Конвертируем целое число в double
        this.untagSmi(regs[0]);
        this.cvtsi2sd(regs[1], regs[0]);

        this.j(done);
        this.bind(nonSmi);

        this.movq(regs[1], this.heapOffset(regs[0], 0));
        this.bind(done);
      }, this);

      var instr = map[operator];

      // Выполняем бинарную операцию
      if (instr) {
        this[instr]('xmm1', 'xmm2');
      } else {
        throw new Error('Unsupported binary operator: ' +
                        operator);
      }

      // Выделяем новое число и складываем в него значение
      // ПРИМЕЧАНИЕ: Последние два аргумента являются
      // аргументами стаба (`size` и `tag`)
      this.stub('rax', 'Alloc', 8, 1);
      this.movq(this.heapOffset('rax', 0), 'xmm1');
    });

    this.Return();
  });
});

Обратите внимание, что стаб также преобразует все входящие числа в double.

Компилятор

И сснова к коду компилятора:

function visitProgram(ast) {
  assert.equal(ast.body.length,
               1,
               'Only one statement programs are supported');
  assert.equal(ast.body[0].type, 'ExpressionStatement');

  // Конвертируем в целое число имеющийся в 'rax' указатель
  visit.call(this, ast.body[0].expression);

  // Получаем число с плавающей запятой из числа кучи
  this.checkSmi('rax', function() {
    // Убираем метку smi
    this.untagSmi('rax');
  }, function() {
    this.movq('xmm1', this.heapOffset('rax', 0));

    // Округляем до нуля
    this.roundsd('zero', 'xmm1', 'xmm1');

    // Конвертируем double в целое число
    this.cvtsd2si('rax', 'xmm1');
  });
}

function visitLiteral(ast) {
  assert.equal(typeof ast.value, 'number');

  if ((ast.value | 0) === ast.value) {
    // SMI, отмеченное значение
    // (т.е. val * 2) с последним битом, приведенным к нулю
    this.mov('rax', utils.tagSmi(ast.value));
  } else {
    // Выделяем новое число кучи
    this.stub('rax', 'Alloc', 8, 1);

    // Сохраняем 'rbx' регистр
    this.spill('rbx', function() {
      this.loadDouble('rbx', ast.value);

      // ПРИМЕЧАНИЕ: Последний бит указателей приведен к единице
      // Поэтому нам нужно использовать процедуру 'heapOffset'
      // чтобы получить доступ к памяти
      this.mov(this.heapOffset('rax', 0), 'rbx');
    });
  }
}

function visitBinary(ast) {
  // Сохраняем 'rbx' после того, как вышли из AST узла
  this.spill('rbx', function() {
    // Посещаем правую сторону выражения
    visit.call(this, ast.right);

    // Перемещаем в 'rbx'
    this.mov('rbx', 'rax');

    // Посещаем левую сторону выражения (результат в 'rax')
    visit.call(this, ast.left);

    //
    // Обобщяя, левая сторона хранится в 'rax', правая - в 'rbx'
    //

    if (ast.operator === '/') {
      // Вызываем стаб для операции деления
      this.stub('rax', 'Binary' + ast.operator, 'rax', 'rbx');
    } else {
      this.labelScope(function() {
        // Проверяем, являются ли оба числа SMI
        this.checkSmi('rax');
        this.j('nz', 'call stub');
        this.checkSmi('rbx');
        this.j('nz', 'call stub');

        // Сохраняем rax в случае смещения
        this.mov('rcx', 'rax');

        // ПРИМЕЧАНИЕ: В этой точке оба 'rax'и 'rbx' являются отмеченными.
        // Метки не нужно убирать, если мы выполняем операции
        // сложения и вычитания. Однако, в случае с
        // умножением, результат будет вдвое больше, если
        // не убрать метки.
        if (ast.operator === '+') {
          this.add('rax', 'rbx');
        } else if (ast.operator === '-') {
          this.sub('rax', 'rbx');
        } else if (ast.operator === '*') {
          this.untagSmi('rax');
          this.mul('rbx');
        }

        // При переполнении восстановить 'rax' из 'rcx' и вызвать стаб
        this.j('o', 'restore');

        // Иначе вернуть'rax'
        this.j('done');
        this.bind('restore');

        this.mov('rax', 'rcx');

        this.bind('call stub');

        // Вызвать стаб и вернуть номер кучи в 'rax'
        this.stub('rax', 'Binary' + ast.operator, 'rax', 'rbx');

        this.bind('done');
      });
    }
  });
}

function visitUnary(ast) {
  if (ast.operator === '-') {
    // Делаем аргумент отрицательным эмулируя бинарное выражение
    visit.call(this, {
      type: 'BinaryExpression',
      operator: '*',
      left: ast.argument,
      right: { type: 'Literal', value: -1 }
    })
  } else {
    throw new Error('Unsupported unary operator: ' + ast.operator);
  }
}

Подведем итоги: теперь мы можем работать с SMI значениями по умолчанию, внедряя ради скорости дополнительные операции, и возвращаться к double значениям в случае переполнения или любых других проблем, вроде попытки найти сумму значений double и SMI!

море узлов [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:26 +0000

Вольный перевод статьи Fedor Indutny "Sea of Nodes"

Море Узлов

Компиляторы = переводчики

Компиляторы это такая вещь, которую каждый разработчик использует несколько раз на дню. К удивлению, даже люди, совсем с кодом не знакомые, также пользуются компляторами. Это потому, что почти весь веб зависит от выполнения кода на стороне клиента и множество подобных программ передаются браузеру в виде исходного кода.

Так мы подходим к важному тезису: пока исходный код читаем человеком, он выглядит настоящим мусором для CPU вашего ноутбука/компьютера/телефона/... . С другой стороны, машинный код, который кмоптютеры могут читать, почти всегда нечитаем человеком. С этим нудно что-то делать, и решением является процесс под названием перевод (translation).

Тривиальные компиляторы выполняют один проход перевода: от исходного кода в машинный. Однако, на практике большинство компиляторов выполняют как минимум два прохода: от исходного кода к абстрактному синтаксическому дереву (Abstract Syntax Tree), и от него к машинному коду. AST в этом случае выступает в качестве Промежуточного Представления (Intermediate Representation), и, как следует из названия, является одним из форматов исходного кода. Эти промежуточные представление связаны друг с другом и, по сути, представляют собой не что иное, как уровни абстракции.

Ограничения на количество уровней нет. Каждый новый слой приближает исходную программу к тому, как она будет выглядет в машинном коде.

Уровни оптимизации

Однако, не все слои используются для одного только перевода. Множество компиляторов также дополнительно пытаются оптимизировать рукописный код. (Который обычно пишется для баланса между элегантностью кода и его производительностью).

В качестве примера рассмотрим следующий JavaScript код:

for (var i = 0, acc = 0; i < arr.length; i++)
  acc += arr[i];

Если компилятор переведет его в машинный код прямиком из AST, то выйдет что-то вроде этого (очень абстрактно и отдаленно от реальности):

acc = 0;
i = 0;
loop {
  // Load `.length` field of arr
  tmp = loadArrayLength(arr);
  if (i >= tmp)
    break;

  // Check that `i` is between 0 and `arr.length`
  // (NOTE: This is necessary for fast loads and
  // stores).
  checkIndex(arr, i);

  // Load value
  acc += load(arr, i);

  // Increment index
  i += 1;
}

Может быть неочевидно, но этот код далек от оптимального. Длина массива внутри цикла не изменяется, и проверять диапазон совсем не обязательно. В идеале, все должно выглядеть вот так:

acc = 0;
i = 0;
len = loadArrayLength(arr);
loop {
  if (i >= tmp)
    break;

  acc += load(arr, i);
  i += 1;
}

Давайте представим, как мы могли бы это сделать.

Допустим, что под рукой у нас уже есть AST, и мы пытаемся сгенерировать из него машинный код:

(ПРИМЕЧАНИЕ: Сгенерировано с помощью esprima)

{ type: 'ForStatement',

  //
  // This is `var i = 0;`
  //
  init:
   { type: 'VariableDeclaration',
     declarations:
      [ { type: 'VariableDeclarator',
          id: { type: 'Identifier', name: 'i' },
          init: { type: 'Literal', value: 0, raw: '0' } },
        { type: 'VariableDeclarator',
          id: { type: 'Identifier', name: 'acc' },
          init: { type: 'Literal', value: 0, raw: '0' } }],
     kind: 'var' },

  //
  // `i < arr.length`
  //
  test:
   { type: 'BinaryExpression',
     operator: '<',
     left: { type: 'Identifier', name: 'i' },
     right:
      { type: 'MemberExpression',
        computed: false,
        object: { type: 'Identifier', name: 'arr' },
        property: { type: 'Identifier', name: 'length' } } },

  //
  // `i++`
  //
  update:
   { type: 'UpdateExpression',
     operator: '++',
     argument: { type: 'Identifier', name: 'i' },
     prefix: false },

  //
  // `arr[i] += 1;`
  //
  body:
   { type: 'ExpressionStatement',
     expression:
      { type: 'AssignmentExpression',
        operator: '+=',
        left: { type: 'Identifier', name: 'acc' },
        right:
         { type: 'MemberExpression',
           computed: true,
           object: { type: 'Identifier', name: 'arr' },
           property: { type: 'Identifier', name: 'i' } } } }

JSON тоже можно визуализировать:

Это дерево, потому по нему можно удобно проходить сверху донизу, генерируя машинный код, когда посещаем его узлы. Проблема этого подхода в том, что информация о переменных очень скудна и распространяется по разным узлам дерева.

Для безопасного перемещения поиска длины из цикла, мы, опять же, должны знать, что длина массива не меняется между его итерациями. Люди могут легко это сделать, взглянув на сам исходный код, но компилятору нужно неплохо поработать, чтобы извлечь эту информацию прямиком из AST.

Как и большинство остальных компиляторных проблем, эта решается путем поднятия данных на более подходязий уровень абстракции, т.е. уровень промежуточного представления. Конкретно в нашем случае такой выбор ПП будет называться потоковым графом (data-flow graph). Вместо того, чтобы говорить об сущностях синтаксиса (вроде for loop, expressions, ...), мы должны говорить о самих данных (чтение, значения переменных) и как они меняются через программу.

Потоковый граф

В нашем примере данные в которых мы заинтересованы это значение переменной arr. Мы хотим иметь возможность легко наблюдать за всеми действиями, чтобы убедиться нет ли у него доступа за пределы допустимого диапазона или каких-либо других изменений, который могли бы изменить длину массива.

Этого можно достигнуть путем введения "def-use" (определение и использования) поведения между разными значениями данных. Это значит, что значение было объявлено один раз (узел) и было использовано для создания новых значений (граница для каждого использования). Очевидно, объединение разных значений сформирует потоковый граф, вроде такого:

Обратите внимание на красный блок array. Стрелки, выходящие из него, представляют использования его значения. Перебирая эти границы, компилятор может определить, что значение array использовалось в:

loadArrayLength
checkIndex
load

Подобные графы строятся так, чтобы явно "клонировать" узел массива, если к его значению был получен деструктивный доступ. (т.е. хранилища, размеры длины). Где бы мы не наблюдали array, в узле или его использованиях, мы всегда должны быть уверены, что его значение не изменяется.

Может звучать сложно, но этого свойства графа достаточно легко достичь, он должен следовать правилам Single Static Assignment (SSA). Вкратце, чтобы конвертировать любую программу в SSA, компилятору нужно переименовать все присваивания и последующие использования переменных, чтобы убедиться что каждая переменная была определена единожды.

Пример до SSA:

var a = 1;
console.log(a);
a = 2;
console.log(a);

После SSA:

var a0 = 1;
console.log(a0);
var a1 = 2;
console.log(a1);

Таким образом, мы, говоря об a0, можем быть уверены, что на самом деле говорим об одном присвоении. Это близко к тому, как люди делают штуки на функциональных языках!

Видя, что loadArrayLength не имеет управляющих зависимостей (i.e. нет пунктирных линий; мы поговорим о них позже), компилятор может заключить, что этот узел можно переместить в любое другое место вне цикла. Проходя по графу глубже, мы можем наблюдать что значение узла ssa:phi всегда находится между 0 и arr.length, потому checkIndex может быть удален польностью.

Довольно аккуратно, не так ли?

Граф потока управления

Представление потока данных может быть очень полезным во многих случаях, но из его проблем заключается в том, что, превращая над код в граф такого вида, мы делаем шаг назад в нашей цепочке представлений (от исходного кода к машинному). Это промежуточное представление для генерации машинного подходит даже меньше, чем AST.

Причина в том что машина представляет собой просто последовательный список инструкций, который CPU выполняет один за другим. Наш финальный граф не отображает этого. По сути, принудительного упорядочивания узлов в нем вообще нет.

Обычно это решается группировкой узлов графа в блоки. Такое представление известно как граф потока управления (Control Flow Graph). Пример:

b0 {
  i0 = literal 0
  i1 = literal 0

  i3 = array
  i4 = jump ^b0
}
b0 -> b1

b1 {
  i5 = ssa:phi ^b1 i0, i12
  i6 = ssa:phi ^i5, i1, i14

  i7 = loadArrayLength i3
  i8 = cmp "<", i6, i7
  i9 = if ^i6, i8
}
b1 -> b2, b3
b2 {
  i10 = checkIndex ^b2, i3, i6
  i11 = load ^i10, i3, i6
  i12 = add i5, i11
  i13 = literal 1
  i14 = add i6, i13
  i15 = jump ^b2
}
b2 -> b1

b3 {
  i16 = exit ^b3
}

Он называется графом не просто так. Например, блоки bXX представляют узлы, а стрелки bXX -> bYY представляют границы. Давайте визуализируем это:

Как вы можете видеть, перед циклом в блоке b0 есть код, а также заголовок цилка в b1, тест цикла в b2, тело цикла в b3 и выход из узла в b4.

Перевод в машинный код становится очень простым благодаря из такого формату. Мы просто заменяем идентификаторы iXX на имена регистров CPU (в каком-то смысле, геристры CPU являются своего рода переменными, CPU имеет ограниченное количество регистров, потому нам надо быть осторожными чтоб они не закончились), и построчно генерируем машинный код для каждой инструкции.

Подводя итоги, CFG имеет связи потоков данных и упорядоченность. Это позволяет нам использовать его как для анализа данных, так и для генерации машинного кода. Однако, попытка оптимизировать CFG путем манипуляций над блоками и их содержимым, может быстро усложниться и стать подверженной ошибкам.

Вместо того, Clifford Click и Keith D. Cooper предложили использовать подход, называемый морем узлов (sea-of-nodes).

Море узлов (Sea-of-Nodes)

Помните наш крутой потоковый граф с пунктриными линиями? Эти пунктирные линии как раз таки делают потоковый граф графом моря узлов.

Вместо группировки в блоки и упорядочивания узлов, мы решили объявить управляющие зависимости в графе, как пунктриные границы. Если мы удалим из графа все непунктирные штуки и немного сгруппируем все, то получим:

Добавим немного воображения и порядка узлам, мы сможем увидеть что этот граф является тем же самым что и упрощенный CFG граф, окторый мы видели выше:

Давайте еще раз вглянем на представление sea-of-nodes:

Разительная разница между этим и CFG графом в том, что здесь нет упорядочивания узлой, кроме тех, которые имеют управляющие зависимости (другими словами, узлы участвуют в в потоке управления).

Это представление - очень мощный способ взглянуть на код. Он знает все об общем графике потока данных и может быть легко изменен без постоянного удаления / замены узлов в блоках.

Сокращения

Говоря об изменениях, давайте обсудим, как изменить график. Граф «море узлов» обычно модифицируется путем сокращения графа. Мы просто ставим в очередь все узлы на графике и вызываем нашу функцию сокращения для каждого узла в очереди. Все, к чему притрагивается эта функция (изменяет, заменяет), ставится назад в очередь и будет передано функции позже. Если у вас есть много сокращений, вы можете просто сложить их вместе и вызвать их все на каждом узле в очереди, или, альтернативно, вы можете просто применить их один за другим, если они зависят от конечного состояния друг друга. Работает прелестно!

Я написал набор инструментов для JavaScript для моих экспериментов с sea-of-nodes, который включает:

json-pipeline - сборщик и stdlib графа. Предоставляет методы для создания узлов, добавления им входных данных, изменения их зависимостей и экспорта/импорта графа из/в данные!
json-pipeline-reducer - движок сокращений. Просто создаем экземпляр редуктора, скармливаем ему функции для сокращения и выполняем редьюсер на уже существующем графе json-pipeline.
json-pipeline-scheduler - библиотека для возврата неупорядоченного графа в ограниченном количестве блоков, соединенных между собой управляющими ребрами (пунктирными линиями).

Объединенные вместе, эти инструменты могут решить множество проблем, который могут быть сформулированы в терминах уравнений потока данных.

Пример сокращения, который будет оптимизировать наш исходный JS код:

for (var i = 0, acc = 0; i < arr.length; i++)

  acc += arr[i];

TL;DR

Этот кусок кода достаточно велик, потому если хотите пропустить его - вот вам заметки о том, что мы делаем с его помощью:

Вычисляем целочисленные диапазоны различных узлов: literal, add, phi
Вычисляем лимиты тела ветки
Применяем диапазон и ограничиваем информацию (i всегда будет неотрицательным числом, ограниченным arr.length) , чтобы сделать вывод, что проверка длины не нужна может быть удалена
arr.length будет убран из цикла автоматически с помощью json-pipeline-scheduler. Потому что для планировки узлов в блоках он совершает Global Code Motion.

// Для просмотра вывода graphviz
var fs = require('fs');

var Pipeline = require('json-pipeline');
var Reducer = require('json-pipeline-reducer');
var Scheduler = require('json-pipeline-scheduler');

//
// Создаем пустой граф с удобными методами CFG.
//
var p = Pipeline.create('cfg');

//
// Парсим данные и генерируем граф.
//
p.parse(`pipeline {
b0 {
i0 = literal 0
i1 = literal 0
```
i3 = array
i4 = jump ^b0
```
}
b0 -> b1

b1 {
i5 = ssa:phi ^b1 i0, i12
i6 = ssa:phi ^i5, i1, i14
```
i7 = loadArrayLength i3
i8 = cmp "<", i6, i7
i9 = if ^i6, i8
```
}
b1 -> b2, b3
b2 {
i10 = checkIndex ^b2, i3, i6
i11 = load ^i10, i3, i6
i12 = add i5, i11
i13 = literal 1
i14 = add i6, i13
i15 = jump ^b2
}
b2 -> b1

b3 {
i16 = exit ^b3
}
}`, { cfg: true }, 'printable');

if (process.env.DEBUG)
fs.writeFileSync('before.gv', p.render('graphviz'));

//
// Создаем хелпер для сокращений
//

function reduce(graph, reduction) {
var reducer = new Reducer();
reducer.addReduction(reduction);
reducer.reduce(graph);

}

//
// Создаем сокращение
//
var ranges = new Map();

function getRange(node) {
if (ranges.has(node))
return ranges.get(node);

var range = { from: -Infinity, to: +Infinity, type: 'any' };
ranges.set(node, range);
return range;
}

function updateRange(node, reducer, from, to) {
var range = getRange(node);

// Самый низкий тип
if (range.type === 'none')
return;

if (range.from === from && range.to === to && range.type === 'int')
return;

range.from = from;
range.to = to;
range.type = 'int';
reducer.change(node);
}

function updateType(node, reducer, type) {
var range = getRange(node);

if (range.type === type)
return;

range.type = type;
reducer.change(node);
}

//
// Устанавливаем тип литерала
//
function reduceLiteral(node, reducer) {
var value = node.literals[0];
updateRange(node, reducer, value, value);
}

function reduceBinary(node, left, right, reducer) {
if (left.type === 'none' || right.type === 'none') {
updateType(node, reducer, 'none');
return false;
}

if (left.type === 'int' || right.type === 'int')
updateType(node, reducer, 'int');

if (left.type !== 'int' || right.type !== 'int')
return false;

return true;
}

//
// Объединяем диапазоны входных данных
//
function reducePhi(node, reducer) {
var left = getRange(node.inputs[0]);
var right = getRange(node.inputs[1]);

if (!reduceBinary(node, left, right, reducer))
return;

if (node.inputs[1].opcode !== 'add' || left.from !== left.to)
return;

var from = Math.min(left.from, right.from);
var to = Math.max(left.to, right.to);
updateRange(node, reducer, from, to);
}

//
// Находим phi = phi + , где начальный phi является числом,
// сообщаем правильный диапазон.
//
function reduceAdd(node, reducer) {
var left = getRange(node.inputs[0]);
var right = getRange(node.inputs[1]);

if (!reduceBinary(node, left, right, reducer))
return;

var phi = node.inputs[0];
if (phi.opcode !== 'ssa:phi' || right.from !== right.to)
return;

var number = right.from;
if (number <= 0 || phi.inputs[1] !== node)
return;

var initial = getRange(phi.inputs[0]);
if (initial.type !== 'int')
return;

updateRange(node, reducer, initial.from, +Infinity);
}

var limits = new Map();

function getLimit(node) {
if (limits.has(node))
return limits.get(node);

var map = new Map();
limits.set(node, map);
return map;
}

function updateLimit(holder, node, reducer, type, value) {
var map = getLimit(holder);
if (!map.has(node))
map.set(node, { type: 'any', value: null });

var limit = map.get(node);
if (limit.type === type && limit.value === value)
return;
limit.type = type;
limit.value = value;
reducer.change(holder);
}

function mergeLimit(node, reducer, other) {
var map = getLimit(node);
var otherMap = getLimit(other);

otherMap.forEach(function(limit, key) {
updateLimit(node, key, reducer, limit.type, limit.value);
});
}

//
// Распространяем лимит от X < Y к правдивой ветке if
//
function reduceIf(node, reducer) {
var test = node.inputs[0];
if (test.opcode !== 'cmp' || test.literals[0] !== '<')
return;

var left = test.inputs[0];
var right = test.inputs[1];

updateLimit(node.controlUses[0], left, reducer, '<', right);
updateLimit(node.controlUses[2], left, reducer, '>=', right);
}

//
// Определяем диапазоны и границы значений.
//

var rangeAndLimit = new Reducer.Reduction({
reduce: function(node, reducer) {
if (node.opcode === 'literal')
reduceLiteral(node, reducer);
else if (node.opcode === 'ssa:phi')
reducePhi(node, reducer);
else if (node.opcode === 'add')
reduceAdd(node, reducer);
else if (node.opcode === 'if')
reduceIf(node, reducer);
}
});
reduce(p, rangeAndLimit);

//
// Теперь, когда у нас есть диапазоны и лимиты,
// время удалить бесполезные проверки
// длины массива.
//

function reduceCheckIndex(node, reducer) {
// Проходим по цепочке управления
var region = node.control[0];
while (region.opcode !== 'region' && region.opcode !== 'start')
region = region.control[0];

var array = node.inputs[0];
var index = node.inputs[1];

var limit = getLimit(region).get(index);
if (!limit)
return;

var range = getRange(index);

// Делаем массив отрицательным, есть индекс невалиден
if (range.from < 0)
return;

// Индекс должен быть ограничен длинной массива
if (limit.type !== '<' ||
limit.value.opcode !== 'loadArrayLength' ||
limit.value.inputs[0] !== array) {
return;
}

// Проверяем, безопасно ли удалять!
reducer.remove(node);
}

var eliminateChecks = new Reducer.Reduction({
reduce: function(node, reducer) {
if (node.opcode === 'checkIndex')
reduceCheckIndex(node, reducer);
}
});
reduce(p, eliminateChecks);

//
// Запускаем планировщик, чтобы положить все
// назад в CFG
//

var out = Scheduler.create(p).run();
out.reindex();

if (process.env.DEBUG)
fs.writeFileSync('after.gv', out.render('graphviz'));

console.log(out.render({ cfg: true }, 'printable'));

ускоренные async функции и промисы [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:11 +0000

Вольный перевод статьи Maya Lekova и Benedikt Meurer "Faster async functions and promises"

Ускоренные async функции и промисы

Традиционно, асинхронность в JavaScript имела репутацию не очень быстрой. Что еще хуже, лайв-отладка JavaScript приложений, в частности серверов Node.js, - непростая задача, особенно когда речь идет об асинхронном программировании. К счастью, времена меняются. В этой статье описано, как мы оптимизировали асинхронные функции и промисы в V8 (и в других JS движках в некоторой степени) и улучшали отладку асинхронного кода.

Примечание: если тексту вы предпочитаете презентацию, ниже приложено видео.

video https://www.youtube.com/watch?v=DFP5DKDQfOc

Новый подход к асинхронному программированию

От коллбэков до промисов и асинхронных функций

Перед тем, как промисы стали частью JavaScript спецификации, для асинхронности обычно использовались API на основе коллбэков, особенно в Node.js. Вот пример:

function handler(done) {
  validateParams((error) => {
    if (error) return done(error);
    dbQuery((error, dbResults) => {
      if (error) return done(error);
      serviceCall(dbResults, (error, serviceResults) => {
        console.log(result);
        done(error, serviceResults);
      });
    });
  });
}

Данный паттерн использует коллбэки глубокой вложенности, что обычно называют “callback hell” (ад коллбэков), поскольку такой метод усложняет поддержку и читабельность кода.

К счастью, промисы теперь являются частью спецификации JavaScript, и тот же код можно сделать более элегантным и поддерживаемым:

function handler() {
  return validateParams()
    .then(dbQuery)
    .then(serviceCall)
    .then(result => {
      console.log(result);
      return result;
    });
}

Совсем недавно JavaScript получил поддержку асинхронных функций. И тот же самый асинхронный код теперь очень схож с синхронным:

async function handler() {
  await validateParams();
  const dbResults = await dbQuery();
  const results = await serviceCall(dbResults);
  console.log(results);
  return results;
}

С асинхронными функциями код становится более коротким, и теперь гораздо легче следить и контролировать потоки данных, несмотря на то, что код выполняется асинхронно. (Заметьте, что выполнение JavaScript кода все еще происходит в одном потоке, потому асинхронные функции сами по себе не создают физических потоков.)

От обработки коллбэков event listener до асинхронной итерации

Еще одна асинхронная парадигма, которая особенно часто используется в Node.js - [ReadableStream](https://nodejs.org/api/stream.html#stream_readable_streams). Вот пример:

const http = require('http');

http.createServer((req, res) => {
  let body = '';
  req.setEncoding('utf8');
  req.on('data', (chunk) => {
    body += chunk;
  });
  req.on('end', () => {
    res.write(body);
    res.end();
  });
}).listen(1337);

Этот код может быть не очень понятным: входные данные обрабатываются чанками, которые доступны только внутри коллбэков, и уведомления об окончании потока тоже происходят внутри коллбэков. И, поскольку функция завершается сразу, а обработка происходит внутри коллбэков, очень легко наткнуться на баги.

Упростить код поможет асинхронная итерация - новая крутая фича ES2018:

const http = require('http');

http.createServer(async (req, res) => {
  try {
    let body = '';
    req.setEncoding('utf8');
    for await (const chunk of req) {
      body += chunk;
    }
    res.write(body);
    res.end();
  } catch {
    res.statusCode = 500;
    res.end();
  }
}).listen(1337);

Все эти новые фичи вы уже можете использовать в продакшене! Асинхронные функции полностью поддерживаются в Node.js 8 (V8 v6.2 / Chrome 62), а асинхронные итераторы и генераторы в Node.js 10 (V8 v6.8 / Chrome 68)!

Улучшение перформанса асинхронности

Нам удалось существенно улучшить производительность асинхронного кода между V8 версии 5.5 (Chrome 55 & Node.js 7) и V8 версии 6.8 (Chrome 68 & Node.js 10). Мы достигли уровня производительности, когда разработчики могут без опаски и не беспокоясь о скорости пользоваться этими новыми парадигмами.

Диаграмма выше показывает замеры doxbee бенчмарка, который замеряет производительность нагруженного промисами кода. Обратите внимание, что график отображают время выполнения, то есть чем меньше, тем лучше.

Результат параллельного бенчмарка, который специально стрессует производительность [Promise.all()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all), еще более интересен:

Мы смогли улучшить производительность Promise.all в 8 раз.

Всё же, оба микро-теста были синтетическими, а команда V8 больше заинтересована в том, как оптимизация повлияла на реальную производительность пользовательского кода.

График выше отображает перформанс нескольких популярных middleware HTTP фреймворков, которые плотно используют промисы и async функции. Заметьте, что данный график, в отличие от прошлых, показывает количество запросов в секунду, потому чем больше, тем лучше. Производительность этих фреймворком была улучшена между Node.js 7 (V8 версии 5.5) и Node.js 10 (V8 версии 6.8).

Такие улучшения производительности появились благодаря трем ключевым достижениям:

TurboFan, новый оптимизирующий компилятор 🎉
Orinoco, новый сборщик мусора 🚛
Исправлению бага Node.js 8, при котором await пропускал микротики 🐛

Мы запустили TurboFan в Node.js 8, что дало огромный прирост в производительности.

Также поработали над новым сборщиком мусора Orinoco, который исключает работу по сбору мусора из основного потока, что, в свою очередь, значительно улучшает обработку запросов.

И последним по списку, но не по важности, было исправление бага Node.js 8, который приводил к тому, что в некоторых случаях await пропускал микротики. Баг считался непреднамеренным нарушением спецификации, но позже дал нам идею, как улучшить производительность. Давайте начнем с объяснения багованного поведения:

const p = Promise.resolve();

(async () => {
  await p; console.log('after:await');
})();

p.then(() => console.log('tick:a'))
 .then(() => console.log('tick:b'));

Код выше создает зарезолвенный промис p, и ожидает его результата с помощью await, но также создает цепочку из двух обработчиков. И в каком же порядке нам стоит ожидать выполнения console.log?

Поскольку p уже выполнен, вы можете ожидать, что первым в консоли появится 'after:await', и только потом оба 'tick'. По факту, так себя и поведет Node.js 8:

Это и есть await баг Node.js 8

Хоть такое поведение и кажется интуитивно понятным - оно не соответствует спецификации. Node.js 10 внедряет правильное поведение, которое сперва выполнит обработчики в цепочке, и только после продолжить асинхронную функцию.

Node.js 10 избавился от await бага

Это “правильное поведение” может вызвать споры или удивить JavaScript разработчиков, а потому заслуживает некоторого пояснения. Давайте начнем с основ, прежде чем погрузимся в волшебный мир промисов и асинхронных функций.

Таски против микротасок

На верхнем уровне JavaScript есть таски и микротаски. Первые обрабатывают события вроде I/O и таймеров, и выполняют их по одному в момент времени. Вторые внедряют отложенное выполнение async/await и промисов, и выполняют их в конце каждого таска. Очередь для микротасок всегда опустошается, прежде чем выполнение вернётся в цикл обработки событий.

Разница между тасками и микротасками

Больше подробностей вы можете найти в статье Джейка Арчибальда "таски, микротаски, очереди и планировки в браузере". Модель задач в Node.js очень схожа.

Асинхронные функции

Как описывает MDN, асинхронная функция - это функция, которая подразумевает асинхронное возвращение промиса в качестве результата. Они предназначены для того, чтобы асинхронный код выглядел как синхронный, тем самым скрывая некоторые сложности асинхронной разработки от разработчика.

Простейшая асинхронная функция выглядит следующим образом:

async function computeAnswer() {
  return 42;
}

После вызова она возвращает промис, данные которого можно получить как при работе с любым другим промисом.

const p = computeAnswer();
// → Промис

p.then(console.log);
// выведет 42 на следующем ходу

Значение промиса p вы получите тогда, когда отработают микротаски. Другими словами, код выше семантически равен использованию Promise.resolve со значением:

function computeAnswer() {
  return Promise.resolve(42);
}

Но настоящая мощь асинхронных функций появляется при использовании выражения await, которое тормозит выполнение функции, пока промис не будет зарезолвлен. Значением await будет выполненный промис. Вот пример для пояснения:

async function fetchStatus(url) {
  const response = await fetch(url);
  return response.status;
}

Выполнение fetchStatus остановится на моменте await, и продолжится только после того, как fetch промис выполнится. Это в какой-то мере эквивалентно цепочке обработчиков промиса, который возвращает fetch.

function fetchStatus(url) {
  return fetch(url).then(response => response.status);
}

Обработчик выполняет те же действия, что и await в асинхронной функции.

Обычно, вы прокидываете Promise в await, но await может ожидать и любого другого JavaScript значения, и, если это значение не является промисом, то будет в него преобразовано. Это означает, что вы можете ожидать даже число (await 42), если нужно:

async function foo() {
  const v = await 42;
  return v;
}

const p = foo();
// → Промис

p.then(console.log);
// в итоге выведет `42`

Более интересно то, что await может работать с “thenable” значениями, т.е. с любым объектом с методом then, даже если он не является настоящим промисом. Таким образом можно реализовывать веселые штуки, вроде асинхронного сна, который измеряет потраченное на него время:

class Sleep {
  constructor(timeout) {
    this.timeout = timeout;
  }
  then(resolve, reject) {
    const startTime = Date.now();
    setTimeout(() => resolve(Date.now() - startTime),
               this.timeout);
  }
}

(async () => {
  const actualTime = await new Sleep(1000);
  console.log(actualTime);
})();

Давайте посмотрим, как V8 обрабатывает await под капотом, следуя спецификации. Возьмем простой пример асинхронной функции foo:

async function foo(v) {
  const w = await v;
  return w;
}

После вызова функции, параметр v оборачивается в промис и выполнение функции останавливается, пока промис не будет зарезолвлен. Как только это произойдет, выполнение продолжится, и возвращаемой переменной w будет присвоено значение выполненного промиса.

`await` под капотом

В первую очередь, V8 помечает функцию, как возобновляемую. Значит, что она может быть приостановлена и возобновлена (в точках await). Затем он создает так называемый implicit_promise, который возвращается, когда вы вызываете асинхронную функцию, и которое в конечном итоге резолвлится до значения, созданного асинхронной функцией.

Сравнение между асинхронной функцией и тем, во что V8 ее превращает

Дальше самое интересное: сам await. В первую очередь, значение, переданное await, оборачивается в промис. Затем к этому промису добавляются обработчики, которые возобновят выполнение функции, как только промис будет выполнен, и выполнение асинхронной функции приостанавливается, возвращая implicit_promise в место вызова. Как только promise будет выполнен, выполнение асинхронной функции продолжится со значением w из promise, и implicit_promise будет зарезолвлен в w.

Короче говоря, основные шаги для await v следующие:

Обернуть v — значение, переданное await — в промис.
Добавить обработчики для последующего возобновления асинхронной функции.
Приостановить выполнение асинхронной функции и вернуть implicit_promise в место вызова.

Давайте шаг за шагом пройдемся по каждой операции. Предположим, что ожидаемое значение уже является промисом, который был выполнен со значением 42. Тогда движок создает новый promise и зарезолвлит его с тем, что было передано в await. Этим самым цепочка промисов откладывается до следующего хода, что в спецификации зовется как [PromiseResolveThenableJob](https://tc39.es/ecma262/#sec-promiseresolvethenablejob).

Затем движок создает так называемый throwaway промис. Называется он throwaway (одноразовый/на выброс), поскольку ни к чему не привязывается и находится только внутри движка. Этот throwaway промис связывается с promise вместе с соответствующими обработчиками для возобновления выполнения асинхронной функции. Операция performPromiseThen, по сути, выражает то, что за кулисами делает метод [Promise.prototype.then()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then). Наконец, выполнение асинхронной функции возобновляется и возвращает контроль в место ее вызова.

Выполнение продолжается в месте вызова, и в итоге стэк вызовов очищается. Потом движок JavaScript запускает микротаски: ранее запланированную [PromiseResolveThenableJob](https://tc39.es/ecma262/#sec-promiseresolvethenablejob), которая говорит [PromiseReactionJob](https://tc39.es/ecma262/#sec-promisereactionjob) сцепить promise со значением, переданным в await. Потом движок возвращает очередь микротасок на обработку, поскольку очередь микротасок должна быть очищена перед обработкой основного цикла событий.

Далее [PromiseReactionJob](https://tc39.es/ecma262/#sec-promisereactionjob), который заполняет promise значением промиса, которого мы ожидаем — 42 — планирует реакцию на throwaway промис. Движок снова возвращает цикл микротасок, который уже содержит финальную микротаску для обработки.

Теперь второй [PromiseReactionJob](https://tc39.es/ecma262/#sec-promisereactionjob) передает разрешение промису throwaway и возобновляет выполнение асинхронной функции, возвращая значение 42 из await.

Суммируя то, что мы выучили, для каждого await движку приходится создавать два дополнительных промиса (даже если значение по правую сторону уже им является) и требует минимум три тика очереди микротасок. Кто знал, что одно await выражение приведёт к такому количеству оверхеда?!

Давайте посмотрим, откуда этот оверхед берется. Первая строка ответственна за создание обёртки промиса. Вторая строка немедленно резолвлит эту обёртку с ожидаемым значением v. Эти две строки ответственны за один дополнительный промис два из трех микротиков. Дороговато, если v уже является промисом (что является частым случаем, т.к. приложения обычно навешивают await на промисы). В редком случае, когда разработчику нужно ожидать await, например, значения 42, движку все равно придется обернуть его в промис.

Как оказалось, в спецификации уже есть операция [promiseResolve](https://tc39.es/ecma262/#sec-promise-resolve), которая будет выполнять обертку только когда нужно:

Эта операция вернет промис неизменным и обернет только необходимые значения. Таким путем вы избавитесь от одного дополнительного промиса и двух тиков, поскольку чаще всего в await мы передаем промис. Это поведение доступно по умолчанию в V8, начиная с версии 7.2.

Вот как работает новый и улучшенный await, шаг за шагом:

Давайте снова предположим, что ожидаем промис со значением 42. Благодаря магии [promiseResolve](https://tc39.es/ecma262/#sec-promise-resolve), promise теперь просто ссылается на такой же промис v, потому на этом шаге больше нет других действий. После того движок действует так же, как и раньше: создает промис throwaway, с помощью [PromiseReactionJob](https://tc39.es/ecma262/#sec-promisereactionjob) планирует возобновить асинхронную функцию на следующем тике в очереди, приостанавливает выполнение функции и возвращает в место вызова.

В итоге все выполнение кода заканчивается и движок запускает микротаски, которые выполняют [PromiseReactionJob](https://tc39.es/ecma262/#sec-promisereactionjob), промису throwaway передается разрешение, выполнение асинхронной функции возобновляется, и из await мы получаем 42.

Эта оптимизация позволяет избежать необходимости оборачивать промис, его значение, переданное в await, уже им является, и вместо трех микротиков мы выполняем только один. Node.js 8 ведет себя также, только это больше не считается багом, а введенной в стандарт оптимизацией!

Но все равно кажется неправильным, что движку приходится создавать промис throwaway, пускай он и является полностью внутренним. Как оказалось, throwaway промис был нужен только для того, чтобы удовлетворить ограничениям внутренней операции performPromiseThen API.

Сравнение await кода до и после оптимизаций

Сравнивая await в Node.js 10 с оптимизированным await версии Node.js 12, видим следующую разницу:

Заключение

Мы ускорили асинхронные функции благодаря двум значительным оптимизациям:

удалением двух дополнительных микротиков
удалением throwaway промиса.

А еще для JavaScript разработчиков у нас есть пара советов по оптимизации:

предпочитайте async / await вручную написанному коду с промисами
придерживайтесь встроенной реализации промисов, предложенной движком, чтобы использовать преимущества шорткатов, т.е. избегайте двух микротиков для await.

DEV Community: собачья будка

как сконвертировать пачку изображений в webp

как наложить блюр в фигме

генерируем xlsx из rss фида

очередной слайдер, которого никто не просил

как я избавлялся от экстремизма в блоге

architectural styles and the design of network-based software architectures. representational state transfer [перевод]

Representational State Transfer (REST)

5.1 Процесс выведения REST

5.1.1 Начиная с Нулевого Стиля

5.1.2 Клиент-сервер

5.1.3 Отсутствие состояния (Stateless)

5.1.4 Кэш

5.1.5 Унифицированный интерфейс

5.1.6 Многоуровневая система

5.1.7 Код по требованию

5.1.8 Summary

5.2 Архитектурные элементы REST

5.2.1 Элементы данных

5.2.1.1 Ресурсы и идентификаторы ресурса

5.2.1.2 Представления

5.2.2 Коннекторы

5.2.3 Компоненты

5.3 Архитектурные представления REST

5.3.1 Представление процесса

5.3.2 Представление коннектора

5.3.3 Представление данных

разбираемся с байткодом v8 [перевод]

Разбираемся с байткодом V8

LdaSmi [1]

Star r0

LdaNamedProperty a0, [0], [4]

Add r0, [6]

Return

как начать just-in-time-ить [перевод]

Как начать Just-In-Time-ить

Предпосылки

С чего начнем

Абстрактное Синтаксическое Дерево (AST)

Машинный код

Генерация кода

Давайте уже напишем это

назначаем числа [перевод]

Назначаем числа

Цели

Stubs

Куча

Bump allocation

Плавающая запятая

smi и double представления [перевод]

SMI и Double представления

Цели

Отметки

Перерабатываем имеющийся код

Назначение

Математические стабы

Компилятор

море узлов [перевод]

Море Узлов

Компиляторы = переводчики

Уровни оптимизации

Потоковый граф

Граф потока управления

Море узлов (Sea-of-Nodes)

Сокращения

TL;DR

ускоренные async функции и промисы [перевод]

Ускоренные async функции и промисы

Новый подход к асинхронному программированию

От коллбэков до промисов и асинхронных функций

От обработки коллбэков event listener до асинхронной итерации

Улучшение перформанса асинхронности

Таски против микротасок

Асинхронные функции

await под капотом

Заключение

`LdaNamedProperty a0, [0], [4]`

`await` под капотом