Integrating Java Dataflow Analysis and the Debugger

栏目: IT技术 · 发布时间: 4年前

内容简介:We have Java Dataflow Analysis (DFA), which is able to derive facts about your program: possible exceptions, conditions that are always true/always false, and more. It performs an abstract interpretation of the source code, allowing it to gather informatio

We have Java Dataflow Analysis (DFA), which is able to derive facts about your program: possible exceptions, conditions that are always true/always false, and more. It performs an abstract interpretation of the source code, allowing it to gather information about the code execution before the code is executed. However, it knows almost nothing about the inputs to the code. Well technically, if the method parameter is annotated as @NotNull the analysis trusts this annotation and assumes that null cannot appear here, but this is only a tiny bit of information.

On the other hand, we have the debugger. When it’s stopped on a breakpoint, it knows pretty much everything about the program: the exact value of every variable and field, the content of every array, and so on. So the debugger knows the present, and DFA can predict the future. Why not feed the present data to DFA and see what will happen?

We have created just such an experimental enhancement to the Java debugger. If you debug the Java source and stay on the breakpoint, it runs the dataflow analysis based on the current program state and sees what will happen next. It doesn’t affect the state of your process, and nothing is executed inside the debugging session. You could think of it loosely as a virtual fork of your process.

What are the benefits of this? The most useful thing is the condition evaluation. It looks like this:

Integrating Java Dataflow Analysis and the Debugger

See the “= false” and “= true” inlay hints? They are added by DFA. Now you know that the first if won’t be visited while the second one will be. It looks like the debugger merely evaluates the expression it sees in the code and displays it. But that’s not exactly the case. See the line if (exception == null) return false; ? The debugger knows that now the exception is null, so exception == null is true. However, DFA also knows that the exception variable may be reassigned by the time this condition is executed. So it doesn’t quickly jump to conclusions, and it shows instead the results only for the conditions that should have the displayed value when they are actually executed. Often it knows that the value of a variable may change, but sometimes it even knows how exactly it will change:

Integrating Java Dataflow Analysis and the Debugger

Here the size has not yet been calculated, but DFA sees into the future and knows that as cst is neither Long nor Double , the size will be initialized to 1, thus size == 1 is true on the next line. Another example:

Integrating Java Dataflow Analysis and the Debugger

The current value of steps is zero, so if you evaluate steps % 128 == 0 then it will be true . However, DFA displays that it’s false . Why? Because steps++ is about to be executed.

DFA can also forewarn you about some known exceptions before they actually happen (unlike static DFA it doesn’t report “possible NPEs”, only the ones it’s sure about), for example:

Integrating Java Dataflow Analysis and the Debugger

As conf is null and clearly doesn’t change before the dereference operator, an NPE is inevitable here and DFA tells you about this. It’s much more convenient to be informed in advance than to end up in a finally block, ten frames above, and not understand why it happened. Here’s another sample:

Integrating Java Dataflow Analysis and the Debugger

We don’t see it in the editor, but preConf.insnIndex is known to be negative at this point. As such, we already know that dfsTree.loopEnters[insnIndex] will fail with AIOOBE. Additionally, DFA currently reports ClassCastException , ArrayStoreException , passing a guaranteed null to a parameter annotated as @NotNull and a method contract violation:

Integrating Java Dataflow Analysis and the Debugger

In the future we may experiment with displaying more values (currently only true and false are displayed). Also, there’s been a suggestion to gray out the blocks of code (e.g. if branches) that are not going to be executed.

Please note that DFA may sometimes be wrong, as it doesn’t actually execute your program. To make the analysis more useful, it makes some reasonable, but not always true, assumptions:

@NotNull
synchronized {}

So sometimes it’s possible that the wrong hint will be displayed, though it should be a rare case.

This feature is available starting with thev2020.1 EAP. If you decide you don’t like this feature, you can switch it off by unchecking the Predict future condition values… option in Preferences / Settings | Build, Execution, Deployment | Debugger | Data Views | Java :

Integrating Java Dataflow Analysis and the Debugger

However, please let us know what you didn’t like about it. Additionally, you can easily switch DFA off temporarily for the current debug session by right-clicking on any displayed hint:

Integrating Java Dataflow Analysis and the Debugger

Your feedback is very welcome. Feel free to add your comments here or to thisYouTrack ticket.

Happy Developing!

Integrating Java Dataflow Analysis and the Debugger

以上所述就是小编给大家介绍的《Integrating Java Dataflow Analysis and the Debugger》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

用户力:需求驱动的产品、运营和商业模式

用户力:需求驱动的产品、运营和商业模式

郝志中 / 机械工业出版社 / 2015-11-1 / 59.00

《用户力:需求驱动的产品、运营和商业模式》从用户需求角度深刻阐释了互联网产品设计、网络运营、商业模式构建的本质与方法论! 本书以“用户需求”为主线,先用逆向思维进行倒推,从本质的角度分析了用户的需求是如何驱动企业的产品设计、网络运营和商业模式构建的,将这三个重要部分进行了系统性和结构化的串联,然后用顺向思维进行铺陈,从实践和方法论的角度总结了企业究竟应该如围绕用户的真实需求来进行产品设计、网......一起来看看 《用户力:需求驱动的产品、运营和商业模式》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

URL 编码/解码
URL 编码/解码

URL 编码/解码

SHA 加密
SHA 加密

SHA 加密工具