Телеграмм чат группы compilerdev страница 626

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Compiler Development

772 membersпожаловаться на группу

2020 January 08

PS

Peter Sovietov in Compiler Development

Aleksey Shipilev

Ну да, stack overflow ловить -- это понятное дело. Но там уж выход за пределы стека -- это 99.999% плохая ситуация, и на перф там уже побоку. А тут можно вполне штатный (и даже написанный юзером) нуллчек свернуть.

Было бы занятно подобным образом ловить ошибки off-by-one выхода за границы массива %)

источник

01:28пожаловаться #1

PS

Peter Sovietov in Compiler Development

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

источник

01:34пожаловаться #2

AS

Aleksey Shipilev in Compiler Development

Было бы занятно подобным образом ловить ошибки off-by-one выхода за границы массива %)

Любой каприз за ваши деньги^W память! Ну и массив неплохо с обеих сторон под страницы подрезать.

источник

01:34пожаловаться #3

E

EgorBo in Compiler Development

@shipilev а у вас нуллпоинтерэкспешн нормально показывает разработчику что именно было нуллом?
например в

x = fuck().duck().suck();

источник

01:37пожаловаться #4

E

EgorBo in Compiler Development

или SIGSEGV не позволит точно показать в стектрейсе?

источник

01:38пожаловаться #5

C

Charm in Compiler Development

@shipilev а у вас нуллпоинтерэкспешн нормально показывает разработчику что именно было нуллом?
например в

x = fuck().duck().suck();

https://openjdk.java.net/jeps/358

источник

01:39пожаловаться #6

AS

Aleksey Shipilev in Compiler Development

или SIGSEGV не позволит точно показать в стектрейсе?

Обработчик знает, в какой машинной инструкции случился SEGV. По этому можно узнать, в какой инструкции байткода случился null. По этому можно тривиально показать на номер строки кода из дебаг-инфы в байткоде, как делается уже давно. Или посмотреть внимательно на байткод и напечатать что-то человеческое, как это делает недавний https://openjdk.java.net/jeps/358

источник

01:41пожаловаться #7

E

EgorBo in Compiler Development

так номер строки - это понятно

источник

01:41пожаловаться #8

E

EgorBo in Compiler Development

а меня интересует какой именно объект в

x = fuck().duck().suck();

источник

01:42пожаловаться #9

E

EgorBo in Compiler Development

может дак вернул нулл, может фак

источник

01:42пожаловаться #10

E

EgorBo in Compiler Development

хотя наверное хрен так получится когда там всё нафиг поинлайнится, наоптимизируется :)

источник

01:43пожаловаться #11

AS

Aleksey Shipilev in Compiler Development

Ну да. Навернулся конкретный invoke*. JVM знает, в каком месте "абстрактной машины" мы навернулись, т.е. знает, какой байткод-инструкции попался null.

источник

01:43пожаловаться #12

AS

Aleksey Shipilev in Compiler Development

Даже если эта байткод-инструкция в реальном сгенерированном машинном коде не существует, этот кусок состояния абстрактной машины нам известен ;)

источник

01:43пожаловаться #13

AS

Aleksey Shipilev in Compiler Development

В байткоде-то номера строк тоже из мапы (bytecode offset, line-no) берутся. Так что если VM умеет печатать номер строки, она уже на полпути к JEP 358.

источник

01:46пожаловаться #14

E

EgorBo in Compiler Development

ну у нас в целом всё так же да :)

источник

01:46пожаловаться #15

E

EgorBo in Compiler Development

мы тут еще в чате недавно обсуждали ллвм пасс с этой штукой

источник

01:47пожаловаться #16

E

EgorBo in Compiler Development

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

источник

01:47пожаловаться #17

E

EgorBo in Compiler Development

(но только те что юзер сам пометил атрибутом !implicit)

источник

01:47пожаловаться #18

AS

Aleksey Shipilev in Compiler Development

угу

источник

01:49пожаловаться #19

E

EgorBo in Compiler Development

так же я так понимаю хендлятся всякие переполнения и деления на ноль

источник

01:51пожаловаться #20