Unless they're completely unreasonable, they won't expect you to hit the ground as an expert next week.
That said, the more you can learn, the more you can impress them. Always good to impress the supervisor.
If you learn by doing, you learn like I do, so I can offer a few recommendations. I assume you have a compiled version of the code. Get familiar with the way the application works, quirks, anything that you think "huh, I don't know how I would do that", any parts that might be cool under the hood. Start there in the code.
Then, if you really want to learn it, start following the flow of data/control through the application. Start at an interesting location, or right at the beginning of user interaction and see how data passes through the system. See what happens at a low level with any user interaction or time based tasks. Take a look and see if there's any points you think that you could optimize or improve, study those points (and if you can, change them and compile them. Don't push a change to management yet if this is a large application, but keep an internal list of things that you can bring up as you get more into the company. Trying to push a change to a system you don't fully understand can have a lot of unexpected sid eeffects, so wait until you fully understand the system.)
However, what it comes down to is: The best thing you can focus on learning fast at a new company is business rules. If there's one central industry you will be working in, learn it. If there's a few, learn all of them. If it's more of a contract to contract business, this will be less applicable.
Anyone can code. But if you understand what the code you're writing does and explain it in explicit business terms, you win.