On 19/09/2016 21:15, Makarius wrote:
The handling of return addresses from functions has been simplified. A consequence of this is that when pieces of code are compiled they are stored in a separate area of memory rather than in the general heap and not garbage-collected.
Does that mean that run-time (re)compilation is a now potential memory leak?
I've heard that the JVM has only recently learned to do proper garbage collection of dynamically loaded modules.
Yes. I can't see a way round it at the moment. It would be difficult to produce an example where the only reference to the code of a function was through the return address but it could happen if a thread started to execute a function contained in a reference and then the reference was overwritten.
Currently, there is a leak because each top-level expression is compiled down to machine code even though the code is only executed once. My plan is to avoid that by interpreting the top-level rather than fully compiling it.
The system has had some basic testing but there are bound to be bugs in something as complex as this. I'm also continuing to work on improvements. When testing this it is essential to run "make compiler" at least once and generally twice to build the new compiler and then build the compiler itself with the new compiler.
I am presently testing Poly/ML 38879127481c and Isabelle 9aed2da07200 and ran into a compiler problem in src/Pure/unify.ML:
Exception- Fail "Exception- InternalError: chooseReg raised while compiling" raised
I'll have a look at that.
Regards, David