avoid creating new strings prior to jar lookup

[richardstartin]

Uses the name we will lookup by as the key in the HashMap during building, which has two effects:

1. Don't need to allocate - this explains some of the unreferenced strings I found in a heap dump taken with EpsilonGC
2. Might not need to compute the hash code during the lookup

I don't think this changes behaviour, but I'm not entirely sure.

[bantonsson]

Can't see that this would change behavior, since these are the only places that filenameToEntry is used.

[richardstartin]

Well, when we shadow, we replace ".class" with ".classdata" and it's not entirely clear to me that the map can only contain our classes. If we take someone else's class and suffix it with "data" prior to lookup and the map contains classes which aren't ours, it would previously miss, but would hit now. Hence the ambivalence despite the obvious benefits.

[richardstartin]

I did a small test with pet clinic where the process exits once the agent is installed to check this didn't have negative consequences. On master:

5.40s user 0.31s system 267% cpu 2.135 total
5.03s user 0.24s system 293% cpu 1.796 total
5.03s user 0.26s system 291% cpu 1.816 total

On this branch:

4.76s user 0.25s system 298% cpu 1.677 total
4.77s user 0.25s system 285% cpu 1.756 total
4.60s user 0.23s system 290% cpu 1.660 total

Take it with a pinch of salt, but this doesn't make things worse for the sake of reduced allocation.

[randomanderson]

While I think it's unlikely, you're right that there could be other items in the jar that end with "data". The easy fix is to check if the suffix is .classdata instead