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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
