https://shipilev.net/jvm-anatomy-park/1-lock-coarsening-for-loops/
во-первых, в любом случае огромное спасибо за этот цикл статей и за эту в частности (кто сказал что критика может быть только негативная =) )
во-вторых, там был вот такой комментарий
; LOL Hotspot, redundant store, killed two lines below
но он был совершенно проигнорирован далее по ходу повествования, что крайне разочаровало меня и пришлось таки идти на stackoverflow и задавать там тупой вопрос https://stackoverflow.com/questions/54316528/redundant-store-in-jit-disassemble ... хорошо Пангин пришёл и показал, что я - лох и ничего не понимаю в jit'те
Ну и третий субьективный пункт там получается заглавный вопрос как-то очень быстро скипается фразой
the downside is potentially coarsening the lock so much, the particular thread would hog the lock while executing a fat loop.
В целом понятно что имеется в виду, но как-то немного хочется подробностей, учитывая, что это топик этой статьи.
Но ещё раз спасибо, было познавательно!
А, да, ещё вопрос здесь: а можно ли утверждать что @CompilerControl(CompilerControl.Mode.DONT_INLINE) влияет одинаково на оба эксперимента? И верно ли это для любого другого бенчмарка?
Надо учиться жить с разочарованиями, потому что всё не опишешь и не расскажешь. Ну да, в моём случае там может быть там входящая снаружи дуга, которой нужна вторая запись. Но первую-то можно было тогда снести, тем более что там прямая дорога между записями. А в твоём примере там куча бранчей между лоадом и стором, и кто его знает, где тот лоад используется.
Обсуждают сегодня