Interesting that you've already profiled that and found where a lot of the memory is going. Still, hundreds of thousands of 8 byte objects is still only maybe a couple of megabytes. Mind if, if you have any non-final methods on that class, it will probably add an extra 4 bytes for a vtable pointer. I bring this up because you said there are a lot of helper methods, and if even one of them is non-final, that vtable pointer will be needed.
Also, I doubt there would be much to gain by replacing those objects with strange packed integers. I would be a little surprised to see any real speed or memory gains (and might even expect some speed loss, depending on how things work out). The cost to clarity and maintenance doesn't seem justified there.
At the moment I'm kind of thinking maybe you should just bite the bullet and start refactoring the existing code. I know refactoring can often seem more daunting than just giving up and doing a rewrite, but refactoring is often the best thing to do. There is a lot to learn from refactoring attempts. Time spent refactoring usually means you better understand the problems you're now facing, and will have a better idea how to solve or avoid these problems in the future. I know it can be a bit of a hassle to actually have to really think about the mess of code you've just realized you've written, but there's also a lot to learn from exactly those types of problems. It's quite helpful to step back from your code once in a while, and forget about how it solves a problem, and instead consider what problem is being solved, and also why you choose to solve this particular problem. I find that last statement is not easy to fully appreciate until you've actually spent some time trying to refactor large projects.
It also good practice to learn how to modify code in small steps. Particularly if you want to work as a programmer. The people paying the bills (such as your salary) are generally not very receptive to the concept of basically throwing away everything they've paid you to develop, and then to continue paying you to develop entirely new stuff that won't be functional for quite some time. If you refactor, it might be that you end up replacing basically everything, but people paying the bills are generally more receptive to the concept of replacing things small parts at a time, so that the whole system remains functional throughout the transition. Plus, it's kind of fun trying to figure out how to replace certain parts of a system without breaking anything. It takes a lot of discipline though. You have to avoid getting sidetracked. It's very easy to try changing too much at once. Just because you've noticed something small and easy to fix while in the middle of making another change, doesn't mean you should fix it now.
I find when I end up refactoring existing code, the majority of my commits only touch about 10 lines at most. I generally strive for the smallest possible change, that's still meaningful, self contained, and doesn't break anything or reduce functionality. Additions of new code are sometimes bigger, but they're usually done in a stepwise manner, so new tested code gets committed, and then another separate commit will modify existing code to place the new code into the code path. You might also remove old code at such a point, but I usually don't do that until a later commit. It's nice to have a commit around in the middle where you can easily switch back and forth between old and new sections of code for testing and verification purposes.
Oh, and btw, with new HTML5 features, such as the Canvas object, that JavaScript joke might have a bit more seriousness to it these days than many of us would like to admit. There are already games being written in pure JavaScript that don't need browser add-ons or embedded applets to run. I still think JavaScript is a bit of a sick and twisted language, and certainly has some maintenance drawbacks, but people who are determined enough certainly seem to be able to do quite a bit with the language.
