Optimizations running even just with D8? [316744331]

Fixed

Bug

Status Update

No update yet.

Description

ms...@gmail.com

created issue #1

Dec 18, 2023 05:02AM

I work on the WALA static analysis framework (https://github.com/wala/WALA), and we use D8 to test WALA's Dalvik frontend. I've been trying to update to the latest D8 version and I ran into an issue with unexpected dead code elimination. Consider the following (weird) Java code from JLex:

	/* Open input stream. */
	m_instream = new java.io.FileReader(filename);
	if (null == m_instream)
	  {
	    System.out.println("Error: Unable to open input file "
			       + filename + ".");
	    return;
	  }

	/* Open output stream. */
	m_outstream 
	  = new java.io.PrintWriter(new java.io.BufferedWriter(
		new java.io.FileWriter(filename + ".java")));
	if (null == m_outstream)
	  {
	    System.out.println("Error: Unable to open output file "
			       + filename + ".java.");
	    return;
	  }

With the old D8 version we were using (2.2.42), the System.out.println calls would be present in the Dalvik bytecode output of D8, even though they are clearly dead code. But with verson 8.2.39, these calls are eliminated. I wouldn't expect D8 alone to be doing this optimization. Here is how we run D8 on a jar:

      D8.run(
          D8Command.builder()
              .addLibraryFiles(path_to_lib)
              .setMinApiLevel(26)
              .setOutput(tmpDir, OutputMode.DexIndexed)
              .addProgramFiles(Paths.get(jarFile))
              .build());

Is the new output expected? I.e., is this level of dead code elimination now "baked in" to D8? Thanks!

Comments

ze...@google.com <ze...@google.com> #2Dec 18, 2023 07:06AM

Reassigned to ze...@google.com.

This was broken by 3bca759a5ff08352de831bb1e9b61b1ec2b3362d.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.

ms...@gmail.com <ms...@gmail.com> #3Dec 18, 2023 03:38PM

Almost 2 months later and this is still broken

ap...@google.com <ap...@google.com> #4Dec 19, 2023 07:17AM

Since there is no progression, I wanted to share our quick-fix for the issue.

#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages

ze...@google.com <ze...@google.com> #5Dec 19, 2023 07:41AM

jb...@google.com What is the update on this?

ze...@google.com <ze...@google.com> #6Dec 19, 2023 07:53AM

What is the status of this item?

ms...@gmail.com <ms...@gmail.com> #7Dec 19, 2023 04:34PM

This has been fixed on master today (internal ref: ag/2945015) and will be available in the next SDK release.

ms...@gmail.com <ms...@gmail.com> #8Dec 28, 2023 05:43PM

Any ETA on next release?

sg...@google.com <sg...@google.com> #9Jan 2, 2024 08:26AM

Still broken and not updated? --package_file argument is not usable in it's current form on 26.1.1 straight from the developer site.

ap...@google.com <ap...@google.com> #10Jan 2, 2024 09:20AM

Comfirmed that this seems to still be broken. Can we have an update please?

```
(15:58:11) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --version
26.1.1

(15:58:17) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --install --package_file=package_file
Warning: Unknown argument --package_file=package_file
```

ap...@google.com <ap...@google.com> #11Jan 4, 2024 08:11AM

Hi, is there any update to this issue? Thanks.

ap...@google.com <ap...@google.com> #12Jan 8, 2024 06:27PM

Hi Google. You claim it's been fixed on master, but we haven't had a new release since the broken version 26.1.1. Can you please release the fix?

ap...@google.com <ap...@google.com> #13Jan 9, 2024 09:43AM

Yeah, still not fixed --'

ap...@google.com <ap...@google.com> #14Jan 9, 2024 09:43AM

Can't believe this still isn't fixed 2 years later for a command line utility that sits on the main dev site.

ap...@google.com <ap...@google.com> #15Jan 9, 2024 02:24PM

Any updates on this? The help for this command clearly states this argument is supported.

ap...@google.com <ap...@google.com> #16Jan 9, 2024 02:24PM

Has anyone re-tried it? We switched back to RUN sdkmanager --package_file=$ANDROID_HOME/packages.txt in our Dockerfile back in March of 2021.

ap...@google.com <ap...@google.com> #17Jan 9, 2024 02:24PM

For what it's worth, I did a quick test with the latest CLI: 11076708 (https://developer.android.com/studio#downloads) on OSX and tried it with a simple:

./sdkmanager --sdk_root="../sdk" --package_file=deps.txt

Deps.txt:

platform-tools
extras;google;instantapps
build-tools;35.0.0-rc3

So perhaps this is now resolved? I haven't tried it with more packages

ap...@google.com <ap...@google.com> #18Jan 9, 2024 02:24PM

Project: r8
Branch: 8.2

commit fd4b26bdc8af1f07472da2af2114e027e53a0efc
Author: Ian Zerny <zerny@google.com>
Date: Tue Jan 09 13:50:35 2024

Version 8.2.46

Bug:

b/316744331

Change-Id: I880c56fd07902c4697105778150be4cc16cd27a6

M src/main/java/com/android/tools/r8/Version.java

https://r8-review.googlesource.com/87973

ap...@google.com <ap...@google.com> #19Jan 9, 2024 02:24PM

Project: r8
Branch: 8.1

commit 59a7c1ac06e0fed85dd2f4f2a710f11fe433640b
Author: Ian Zerny <zerny@google.com>
Date: Tue Jan 09 12:13:37 2024

Reland "Disable redundant load elimination in debug mode"

Notice: this cherry pick is written manually as this branch is from
before the introduction of code rewriter passes.

Bug:

b/316744331

Bug:

b/218282718

Change-Id: I1c4fba711609183130735f8b93d0dbe627dec1c1

M src/main/java/com/android/tools/r8/ir/optimize/RedundantFieldLoadAndStoreElimination.java

https://r8-review.googlesource.com/87928

ap...@google.com <ap...@google.com> #20Jan 9, 2024 02:24PM

Project: r8
Branch: 8.1

commit 916a6d04b1c84a95bca923f2ea273fd7d52532fa
Author: Ian Zerny <zerny@google.com>
Date: Tue Jan 09 12:14:41 2024

Version 8.1.78

Bug:

b/316744331

Change-Id: I00bd2fac3a2548883838209d239b7fd200a54da0

M src/main/java/com/android/tools/r8/Version.java

https://r8-review.googlesource.com/87929

ze...@google.com <ze...@google.com> #21Jan 11, 2024 08:43AM

Marked as fixed.

A fix has been pushed to 8.0, 8.1, 8.2 and 8.3 branches for R8.

To use one of the fixed versions without AGP updates amend your settings.gradle or settings.gradle.kts file with:

pluginManagement {
    buildscript {
        repositories {
            mavenCentral()
            maven {
                url = uri("https://storage.googleapis.com/r8-releases/raw")
            }
        }
        dependencies {
           classpath("com.android.tools:r8:8.2.46") // <-- Use version matching your AGP here
        }
    }
}

Since AGP 8, the R8 versions follow those of AGP, so if using AGP 8.2 use the latest version on the R8 8.2 branch (for this issue 8.2.46 or any later patch version).

ms...@gmail.com <ms...@gmail.com> #22Jan 15, 2024 12:01AM

Thank you for fixing this issue!

an...@google.com <an...@google.com> #23Jan 23, 2024 06:00PM

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

Android Studio Hedgehog | 2023.1.1 Patch 2
Android Gradle Plugin 8.2.2

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

so...@google.com <so...@google.com> #24Jan 27, 2024 11:41PM

Comment added by automation: A postmortem has been automatically requested for this issue. Please author a postmortem on IRM. See go/android-postmortem-guidance for more context and details, including how to handle the case when this issue does not need a postmortem. If you have any questions not answered by go/android-postmortem-guidance, please email android-hygiene-tpm@, instead of reassigning the fixed bug. Thank you.

an...@google.com <an...@google.com> #25Feb 5, 2024 05:57PM

The fixes for this issue are now also available in:

Android Studio Iguana | 2023.2.1 RC 1
Android Gradle Plugin 8.3.0-rc01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Issue 316744331

Description

Issue summary

Comments

ze...@google.com <ze...@google.com> #2Dec 18, 2023 07:06AM

ms...@gmail.com <ms...@gmail.com> #3Dec 18, 2023 03:38PM

ap...@google.com <ap...@google.com> #4Dec 19, 2023 07:17AM

ze...@google.com <ze...@google.com> #5Dec 19, 2023 07:41AM

ze...@google.com <ze...@google.com> #6Dec 19, 2023 07:53AM

ms...@gmail.com <ms...@gmail.com> #7Dec 19, 2023 04:34PM

ms...@gmail.com <ms...@gmail.com> #8Dec 28, 2023 05:43PM

sg...@google.com <sg...@google.com> #9Jan 2, 2024 08:26AM

ap...@google.com <ap...@google.com> #10Jan 2, 2024 09:20AM

ap...@google.com <ap...@google.com> #11Jan 4, 2024 08:11AM

ap...@google.com <ap...@google.com> #12Jan 8, 2024 06:27PM

ap...@google.com <ap...@google.com> #13Jan 9, 2024 09:43AM

ap...@google.com <ap...@google.com> #14Jan 9, 2024 09:43AM

ap...@google.com <ap...@google.com> #15Jan 9, 2024 02:24PM

ap...@google.com <ap...@google.com> #16Jan 9, 2024 02:24PM

ap...@google.com <ap...@google.com> #17Jan 9, 2024 02:24PM

ap...@google.com <ap...@google.com> #18Jan 9, 2024 02:24PM

ap...@google.com <ap...@google.com> #19Jan 9, 2024 02:24PM

ap...@google.com <ap...@google.com> #20Jan 9, 2024 02:24PM

ze...@google.com <ze...@google.com> #21Jan 11, 2024 08:43AM

ms...@gmail.com <ms...@gmail.com> #22Jan 15, 2024 12:01AM

an...@google.com <an...@google.com> #23Jan 23, 2024 06:00PM

so...@google.com <so...@google.com> #24Jan 27, 2024 11:41PM

an...@google.com <an...@google.com> #25Feb 5, 2024 05:57PM

Add comment

Issue metadata