RFR: 8143730 [JVMCI] infopoint recording is too restrictive

[Christian Thalinger]

Looks good.

> On Nov 26, 2015, at 2:35 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> There’s new webrev for this change:
> 
> http://cr.openjdk.java.net/~dnsimon/8143730v2/
> 
> which adopts this bug fix:
> 
> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/e9424bc1e288)
> 
> -Doug
> 
>> On 25 Nov 2015, at 20:24, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> 
>>> On Nov 25, 2015, at 8:56 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>> 
>>>> On 25 Nov 2015, at 19:50, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> 
>>>> 
>>>>> On Nov 23, 2015, at 1:16 PM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>> 
>>>>> JVMCI compilers can optionally record extra debug info for compiled code in addition to the debug info required for safepoints, calls and exceptions. This is the kind of extra information recorded for  -XX:+DebugNonSafepoints. Currently, CompilationResult only allows one piece of debug info to be recorded per machine code position. This means the compiler has to insert extra no-ops if it does not want to discard any of the extra debug info. 
>>>>> 
>>>>> The proposed change here is to relax the constraint in the VM independent JVMCI code. If the VM only supports one piece of debug info per machine code position, it should have local logic to decide which of multiple debug infos to record when installing code.
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8143730
>>>>> http://cr.openjdk.java.net/~dnsimon/8143730/
>>>> 
>>>> src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InfopointReason.java:
>>>> 
>>>> -    LINE_NUMBER(true),
>>>> 
>>>> I see usages of InfopointReason.LINE_NUMBER in Graal code.  What’s the deal here?
>>>> 
>>>> Also, there is one test that uses UNUSED:
>>>> 
>>>> graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/JVMCIErrorTest.java
>>>> 163:        test(r -> r.addInfopoint(new Infopoint(0, null, InfopointReason.UNKNOWN)));
>>> 
>>> The Graal usages of LINE_NUMBER will be refactored to use BYTECODE_POSITION instead and the test using UNUSED will be deleted. The original choice of LINE_NUMBER captures the sole purpose for this infopint at the time. However, the information recorded is only a bytecode position. The consumer of such infopoints still has to do the translation to a line number.
>> 
>> Understood.  This looks good then.
>