-XX:Inline ignored for system classes?

[Peter Veentjer]

I have a related question. A lot of code looks like this.

public class Devirtualization_Field {

    private final List list = new ArrayList();

    public static void main(String[] args) {
        Devirtualization_Field f = new Devirtualization_Field();

        int result = 0;

        for (int k = 0; k < 10_000; k++) {
            result += f.sizePlusOne();
        }


        System.out.println("result:" + result);
    }

    public int sizePlusOne() {
        return list.size() + 1;
    }
}

So you have some kind of implementation and you assign it to a variable
that uses the interface.
This is considered a good practice: liskov substitution principle

However if I look at the Assembly of sizePlusOne, I still see the typeguard
for ArrayList. See Assembly
at the end.

My questions are the following:
- is the compiler not able to proof that list is of type ArrayList; so
sharpening the type?
- if it is able to proof, then I guess reflection is the reason why this
type guard is needed. Then perhaps a dumb question: instead of adding this
typeguard, why not add a trap in the reflection that causes the code to get
deoptimized? Now there is a price to pay even if the field isn't changed
with reflection. Then the burden will be placed on reflection instead.

The assembly

 0x000000010b07e680: mov    DWORD PTR [rsp-0x14000],eax
  0x000000010b07e687: push   rbp
  0x000000010b07e688: sub    rsp,0x10           ;*synchronization entry
                                                ; -
com.devirtualization.Devirtualization_Field::sizePlusOne at -1 (line 27)

  0x000000010b07e68c: mov    r11d,DWORD PTR [rsi+0xc]  ;*getfield list
                                                ; -
com.devirtualization.Devirtualization_Field::sizePlusOne at 1 (line 27)

  0x000000010b07e690: mov    r10d,DWORD PTR [r12+r11*8+0x8]
                                                ; implicit exception:
dispatches to 0x000000010b07e6c9
  0x000000010b07e695: cmp    r10d,0xf8003231    ;
{metadata('java/util/ArrayList')}
  0x000000010b07e69c: jne    0x000000010b07e6b4
  0x000000010b07e69e: lea    r10,[r12+r11*8]    ;*invokeinterface size
                                                ; -
com.devirtualization.Devirtualization_Field::sizePlusOne at 4 (line 27)

  0x000000010b07e6a2: mov    eax,DWORD PTR [r10+0x10]
  0x000000010b07e6a6: inc    eax                ;*iadd
                                                ; -
com.devirtualization.Devirtualization_Field::sizePlusOne at 10 (line 27)

  0x000000010b07e6a8: add    rsp,0x10
  0x000000010b07e6ac: pop    rbp
  0x000000010b07e6ad: test   DWORD PTR [rip+0xffffffffff64194d],eax
 # 0x000000010a6c0000
                                                ;   {poll_return}
  0x000000010b07e6b3: ret
  0x000000010b07e6b4: mov    esi,0xffffffde
  0x000000010b07e6b9: mov    ebp,r11d
  0x000000010b07e6bc: data32 xchg ax,ax
  0x000000010b07e6bf: call   0x000000010b047120  ; OopMap{rbp=NarrowOop
off=100}
                                                ;*invokeinterface size
                                                ; -
com.devirtualization.Devirtualization_Field::sizePlusOne at 4 (line 27)
                                                ;   {runtime_call}
  0x000000010b07e6c4: call   0x0000000109afce44  ;   {runtime_call}
  0x000000010b07e6c9: mov    esi,0xfffffff6
  0x000000010b07e6ce: nop
  0x000000010b07e6cf: call   0x000000010b047120  ; OopMap{off=116}
                                                ;*invokeinterface size
                                                ; -
com.devirtualization.Devirtualization_Field::sizePlusOne at 4 (line 27)
                                                ;   {runtime_call}
  0x000000010b07e6d4: call   0x0000000109afce44  ;*invokeinterface size
                                                ; -
com.devirtualization.Devirtualization_Field::sizePlusOne at 4 (line 27)
                                                ;   {runtime_call}


On Sun, Jan 22, 2017 at 6:30 PM, Peter Veentjer <alarmnummer at gmail.com>
wrote:

> Thanks! I have learned something new.
>
> On Sun, Jan 22, 2017 at 6:26 PM, Andrew Haley <aph at redhat.com> wrote:
>
>> On 22/01/17 12:52, Peter Veentjer wrote:
>> > I'm doing some Assembly analysis to gain a deeper understanding in
>> > devirtualization and I'm running into some unexpected behavior. What I'm
>> > seeing is that even though inlining is disabled, the call to
>> ArrayList.size
>> > got inlined. Look for '0x000000010be7e539' and you will see the
>> unexpected
>> > behavior. Is this intentional behavior or am I missing something?
>>
>> Accessors are special.  Try -XX:-InlineAccessors.
>>
>> Andrew.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170122/4f9add07/attachment-0001.html>