Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decompiler cache causes suboptimal results when reused #1117

Open
VelizarBG opened this issue May 5, 2024 · 8 comments · Fixed by #1118
Open

Decompiler cache causes suboptimal results when reused #1117

VelizarBG opened this issue May 5, 2024 · 8 comments · Fixed by #1118
Milestone

Comments

@VelizarBG
Copy link

VelizarBG commented May 5, 2024

When the decompiler cache gets reused weird changes occur, which aren't present when generating the sources without using the cache.

This seems to happen when a big amount of cache hits are present, as is the case between two versions of the game that are adjacent in time, and when adding/removing an access widener entry. In the first case it pollutes the diff quite a lot, and reduces readability in both cases.

Steps to reproduce

  1. Delete your decompiler cache.
  2. Clone the reproduction repo.
  3. Checkout the 1.20.6 branch.
  4. Run gradlew genSourcesWithVineflower --use-cache
  5. Checkout the 24w18a branch.
  6. Repeat step 3.
  7. Store a copy of the generated sources somewhere.
  8. Run gradlew genSourcesWithVineflower --no-use-cache
  9. Diff the sources generated with cache and the ones without.
  10. Notice the suboptimal differences(e.g. missing @Override annotations, unnecessary casts, missing generics, and so on).

PS: This also applies to the CFR decompiler. Haven't tested FernFlower.

@modmuss50
Copy link
Member

Humm, intresting. I can see that being an issue, the easy fix for this is to not share the caches between diffrent versions. Or take into account the entire class hierarchy when calcuating the cache key. 🤔

@VelizarBG
Copy link
Author

Just tested it with access wideners, and it seems to be an issue there as well :/
Though, quite importantly, the defects only happen in the classes that the cache misses.

@isXander
Copy link

isXander commented May 5, 2024

Humm, intresting. I can see that being an issue, the easy fix for this is to not share the caches between diffrent versions. Or take into account the entire class hierarchy when calcuating the cache key. 🤔

Not sharing cache between versions would be a huge bummer. A lot of the times there a loads of cache hits as you probably know.

@VelizarBG VelizarBG changed the title Decompiler cache causes suboptimal results when reused for a different version Decompiler cache causes suboptimal results when reused May 8, 2024
@VelizarBG
Copy link
Author

VelizarBG commented May 8, 2024

Updated the title and description to better suite the scope of the issue. I'd also post actual examples, but not sure if that's a great idea.

@VelizarBG
Copy link
Author

@modmuss50 Thanks so much for the fix! All of the defects seem to be gone, except for the one with the weird imports for inner classes(sometimes they are imported explicitly, other times referenced by their fully qualified name). It's not a big deal but it'd be nice if it could be mitigated.

@modmuss50
Copy link
Member

@modmuss50 Thanks so much for the fix! All of the defects seem to be gone, except for the one with the weird imports for inner classes(sometimes they are imported explicitly, other times referenced by their fully qualified name). It's not a big deal but it'd be nice if it could be mitigated.

Are you seeing this when switching between MC versions or when enabling/disabling AWs?

@VelizarBG
Copy link
Author

I tested the former. Let me also try the latter...
Yep, it's an issue there as well.

@modmuss50
Copy link
Member

Ok, thanks. Ill take another look.

Ill re-open the issue so I dont forget 👍

@modmuss50 modmuss50 reopened this May 14, 2024
@modmuss50 modmuss50 modified the milestones: 1.7, 1.8 Jun 14, 2024
@modmuss50 modmuss50 modified the milestones: 1.8, 1.9 Sep 24, 2024
@modmuss50 modmuss50 modified the milestones: 1.9, 1.10 Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants