From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Wed Jan 20 1999 - 14:14:14 EST
On Jan 20, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>>
>> When I test it with intrp engine, I found 2 new bugs:
>> - lt_dlopen() need more stack (more than 8Ko).
> I see. The allocate several 1k arrays on the stack.
> Alexandre can fix that.
Certainly. I'm in the process of rewriting lt_dlopen to introduce in
another way the ability to dlopen non-libtool libraries, and I'll try
to reduce the stack usage. It shouldn't be that hard, if I can use
malloc/free.
Another option would be to create a dlopening thread, controlled
mostly like the garbage collector, which would also take care of the
locking issue (would it?). This would avoid requiring much stack
space for all threads. Or we could just switch to a separate stack
for dlopening (Ugh! :-)
> Should there be problems with relying on malloc/free, please
> make it an #ifdef option.
BTW, libltdl currently already calls malloc/free, do we really have to
change that for kaffe?
>> - fix ExecTest that don't read pipe result of /bin/ls, I use /bin/echo
> You know, I don't understand why that always worked for me.
Certainly a difference in pipe buffer size.
>> Today, all work as before (with -ss 64K) with intrp and jit on i386.
> Yes, we need to keep the stack size as small as possible with our
> current stack allocation scheme. It's a scalability issue.
Certainly.
> Clearly, that's no good. Let's hope the libtool folks won't argue
> that that's a serious problem.
I certainly won't. I hope Tanner and I don't enter yet another
series of reverting patches from one another :-)
> native() is also not thread safe in the intr either. It's in the todo list.
> There may be a bootstrapping issue.
Which may defeat the suggestion of creating the separate thread for
dlopening only.
But I've just checked that Runtime.load and Runtime.loadLibrary are
synchronized, so there's no need for any additional locking, since the
only other situation in which we call loadLibrary (native) is at
bootstrap time, for libnative.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:47 EDT