From: Godmar Back (gback@cs.utah.edu)
Date: Wed Jan 20 1999 - 15:32:57 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.
Great.
>
> 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! :-)
Although that's not a solution I'd exclude, I think fixing the
excessive stack needs of libltdl sounds like a better overall solution.
>
> > 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?
No, that's not what I meant. I noticed that it calls malloc/free in
places. I thought libltdl would allocate the large arrays on the
stack on purpose, for instance because they cannot call malloc/free ---
say the user uses libltdl to dynamically redirect the resolution of
malloc/free. But what do I know if libltdl even allows that.
As an aside, the issue of restricting stack space is not just a
problem in libltdl. It's also problem in kaffevm and libnative.
Plus, we have to account for stupid libc implementations as well.
The BeOS guy for instance reported that he had to raise his
high stack mark (STACK_HIGH) to get things to run.
Since I do not envision us using automatically growing stacks in
the near future (except for the linux native thread port), it is
essential that we keep stack usage to a minimum. (Which may mean
to reduce MAXARGS in support.c, btw.)
The second problem is the high stack mark, which represents
a memory reserve that we check against whenever we enter a method.
If a native method requires an excessive amount of stack space,
not only do we need to allocate more memory per thread, but we
also waste more due to the stack high water mark.
Another possibility would be to provide a backdoor interface to
create threads with a specified thread size.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:47 EDT