What is the mechanism for converting source code or an in-memory image (or fragment thereof) into a deployable unit? Just point me at a function name/document and I can take it from there. . . .
Thanks, Matt
ABCL currently can not save a memory image, so you're stuck with loading compiled files (perhaps with asdf or similar, if it accepts the absence of source files). ABCL has the capability to load files from a jar archive, but I think it's internal machinery and not exposed through a public API, though I might be wrong on this point. However, loading files from a jar probably forces you to drop asdf and any other system definition facility and manually load files in the correct order.
hth, Alessio
On Tue, Jul 21, 2009 at 2:52 PM, Matt Lamarimatt.lamari@gmail.com wrote:
What is the mechanism for converting source code or an in-memory image (or fragment thereof) into a deployable unit? Just point me at a function name/document and I can take it from there. . . .
Thanks, Matt
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
What's the planned endgame for the system? Is saved-memory-image remotely feasible? Or a jar with coded that would create the image? Or something else?
Alessio Stalla wrote:
ABCL currently can not save a memory image, so you're stuck with loading compiled files (perhaps with asdf or similar, if it accepts the absence of source files). ABCL has the capability to load files from a jar archive, but I think it's internal machinery and not exposed through a public API, though I might be wrong on this point. However, loading files from a jar probably forces you to drop asdf and any other system definition facility and manually load files in the correct order.
hth, Alessio
On Tue, Jul 21, 2009 at 2:52 PM, Matt Lamarimatt.lamari@gmail.com wrote:
What is the mechanism for converting source code or an in-memory image (or fragment thereof) into a deployable unit? Just point me at a function name/document and I can take it from there. . . .
Thanks, Matt
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Tue, Jul 21, 2009 at 8:46 PM, Matt Lamarimatt.lamari@gmail.com wrote:
What's the planned endgame for the system? Is saved-memory-image remotely feasible? Or a jar with coded that would create the image? Or something else?
Disclaimer: I'm speaking for myself and not on behalf of abcl developers in general, since as far as I know this issue has not been discussed in detail and so no official position exists.
I see two possible options to resolve the issue. One is to implement save-image using Java serialization. I made an attempt at this some time ago, but stopped for a number of reasons - the most prominent is that, as far as I can tell, abcl's compiler should not rely on temporary files as it does now, or serializing compiled functions is not feasible. There's interest in me and others to do this change to the compiler for other reasons too, but it's not a trivial change and so far it's not the most important issue, so it's not high priority. The other solution, maybe less optimal but much easier imho, is to expose the api for loading files from jars and integrate it with LOAD (that is, with Lisp pathnames), and maybe provide a nice function to package a bunch of compiled Lisp files (say, from a given directory) into a jar to be deployed together with abcl.jar. I haven't thought about this in depth so there might be conceptual problems, I don't know. But if it can be done, it's not hard to do. The two solutions are not mutually exclusive and could be both implemented. As far as I'm concerned, I'm currently concentrating on other things but in future I'd like to try both solutions, because I think abcl would greatly benefit from them.
Cheers, Alessio
Alessio Stalla wrote:
ABCL currently can not save a memory image, so you're stuck with loading compiled files (perhaps with asdf or similar, if it accepts the absence of source files). ABCL has the capability to load files from a jar archive, but I think it's internal machinery and not exposed through a public API, though I might be wrong on this point. However, loading files from a jar probably forces you to drop asdf and any other system definition facility and manually load files in the correct order.
hth, Alessio
On Tue, Jul 21, 2009 at 2:52 PM, Matt Lamarimatt.lamari@gmail.com wrote:
What is the mechanism for converting source code or an in-memory image (or fragment thereof) into a deployable unit? Just point me at a function name/document and I can take it from there. . . .
Thanks, Matt
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
"as" == Alessio Stalla alessiostalla@gmail.com writes:
as> The other solution, maybe less optimal but much easier imho, is to as> expose the api for loading files from jars and integrate it with LOAD as> (that is, with Lisp pathnames), and maybe provide a nice function to as> package a bunch of compiled Lisp files (say, from a given directory) as> into a jar to be deployed together with abcl.jar. I haven't thought as> about this in depth so there might be conceptual problems, I don't as> know. But if it can be done, it's not hard to do.
I've had a first stab at doing this; it works OK in light testing.
To compile files to a zip file (existing functionality in ABCL), do
(let ((sys::*compile-file-zip* t)) (compile-file "foo.lisp" :output-file "/tmp/foo.jar"))
To load from that jar, apply the attached patch and use
(load "jar:file:/tmp/foo.jar!/foo")
You can bundle your compiled files with ABCL in a single jar and load directly from that (you'd need to fiddle with "getResource" to know your home jar filename; possibly we should set EXT:*LISP-HOME* to that when running from a jar).
Parameterized Lisp Calls vs Array Calls In the code I added a Interface "barrier" just in-case there was some inlining
/***********************START JAVA*************************************************/ package benchtest;
interface ISomeFunParams { int SomeFun(int i, int j); }
interface ISomeFunArray { int SomeFun(int[] ij); }
interface ISomeFunVarArgs { int SomeFun(int... ij); }
class BenchArrays1 {
public static void main(String[] args) {
ISomeFunParams sumFun = new SomeFunImpl1();
int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); }
// make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } }
class BenchArrays2 {
public static void main(String[] args) {
ISomeFunVarArgs sumFun = new SomeFunImpl2();
int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); }
// make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } }
class BenchArrays3 {
public static void main(String[] args) {
ISomeFunArray sumFun = new SomeFunImpl3();
int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(new int[]{i, j}); }
// make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } }
class SomeFunImpl1 implements ISomeFunParams { public int SomeFun(int i, int j) { return i + j; } }
class SomeFunImpl2 implements ISomeFunVarArgs { public int SomeFun(int... ij) { return ij[0] + ij[1]; } }
class SomeFunImpl3 implements ISomeFunArray { public int SomeFun(int[] ij) { return ij[0] + ij[1]; } } /***********************END JAVA*************************************************/
[root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays1
real 0m0.113s user 0m0.040s sys 0m0.013s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays2
real 1m42.898s user 1m21.279s sys 0m0.742s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays3
real 1m40.823s user 1m21.411s sys 0m0.651s
armedbear-devel@common-lisp.net