Switch expressions with no type cases, generates dead code to deal with type cases [396219788]

Assigned

Bug

Status Update

No update yet.

Description

ma...@google.com

created issue #1

Feb 12, 2025 11:57PM

Forked off from b/395999911#comment7

This switch expression: https://godbolt.org/z/Y61z468qM:

class SwitchDiff {
    static int pattern(Cat c) {
        return switch (c) {
            case Foo.A -> 1;
            case Foo.B -> 2;
            case Bar.A -> 3;
            case Bar.B -> 4;
            default -> 5;
        };
    }
}

generates some code that has handling for class switch statements like case String s:, even though this switch has no such typed cases.

    instance-of v1, v0, Ljava/lang/Class;

    #@b
    if-eqz v1, :cond_16

    #@d
    check-cast v0, Ljava/lang/Class;

    #@f
    invoke-virtual {v0, p0}, Ljava/lang/Class;->isInstance(Ljava/lang/Object;)Z

This checks if each element of the getSwitchCases() array is a class, which slows down the switch a little for each iteration.

Could we avoid emitting this code for switch expressions that don't have type cases?

The code is here: https://r8.googlesource.com/r8/+/refs/heads/main/src/main/java/com/android/tools/r8/ir/desugar/typeswitch/TypeSwitchMethods.java#112

Comments

ma...@google.com <ma...@google.com> #2Feb 13, 2025 12:06AM

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.

Android bug report (to be captured after reproducing the issue on latest public build)
For steps to capture a bug report, please refer:

https://developer.android.com/studio/debug/bug-report#bugreportdevice

Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.

Note: Please upload the bug report to google drive and share the folder to android-bugreport@google.com, then share the link here.

sg...@google.com <sg...@google.com> Feb 13, 2025 07:45AM

Reassigned to cl...@google.com.

sg...@google.com <sg...@google.com> #3Feb 13, 2025 08:56AM

The easiest way to reproduce the issue is by using an app like Nordic's nRF Connect for Mobile from Google Play.

Prerequisites:
Any BLE device you can create a GATT connection to

Steps to reproduce:

Open nRF Connect for Mobile
Discover the BLE device
Create a connection to the BLE device
Pull from the left side of the screen in nRF to reveal the log window (or look at logcat on a connected computer)
Terminate the BLE connection by powering off or taking the BLE device out of range

Expected result:
If the BLE device is taken out of range, the GATT status value in onConnectionStateChanged() should be '8' (GATT_CONN_TIMEOUT), like on all previous Android versions with BLE support.
If the BLE device terminates the connection, the GATT status value in onConnectionStateChanged() should be '19' (GATT_CONN_TERMINATE_PEER_USER), like on all previous Android versions with BLE support.

The GATT status should only be '0' when the app closes the connection via a call to BluetoothGatt#disconnect().

Actual result:
In Android 12, regardless how the BLE connection is terminated the GATT status is always '0'.

See attached screen shot ('Comparison.png') for a comparison between an older Android version and Android 12.

Pixel 12:
GATT_CONN_TIMEOUT, disconnect reason 8:
2021-11-29 11:48:13.635 13689-13722/? D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=9 device=xx:xx:xx:xx:xx:xx

GATT_CONN_TERMINATE_PEER_USER, disconnect reason 19:
2021-11-29 11:53:02.644 13689-21741/? D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=9 device=xx:xx:xx:xx:xx:xx

Bugreport
https://drive.google.com/file/d/19ASZ6bVYXRuhRt_NjsRs_-YnWOiUGcyN/view?usp=drive_web (bugreport-flame-SP1A.210812.015-2021-11-29-11-53-20.zip)

ma...@google.com <ma...@google.com> #4Feb 13, 2025 11:45PM

Correction to #3:
The headline 'Pixel 12' should have been: 'Pixel 4, Android 12'. 😀

cl...@google.com <cl...@google.com> #5Feb 26, 2025 07:04AM

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Issue 396219788