JDK garbage collector: thread context scanning

[Alexey Zelkin]

hi,

On Fri, Feb 06, 2004 at 11:54:01AM +0000, Nick Barnes wrote:
> At 2004-02-05 23:32:33+0000, Alexey Zelkin writes:
> 
> > Since JDK 1.4.1 we got correctly working fallbacks, so I was not
> > required to do a black magic anymore.
> 
> Can you enlarge on this?  What are "correctly working fallbacks"?

It means that if callback (used in pthread_kill()/sighandler()) schema
does not return meaningful value (i.e. NULL) then JVM tries to detect
this value with own way.  It is slower solution, but works for us in all
cases (both -STABLE and -CURRENT with any thread libraries)

> > Lately I have implemented pthread_attr_get_np() function which
> > exported all required information on application level and we stoped
> > to use private libc_r structures in JDK 1.4.x
> 
> Which information delivered by pthread_attr_get_np() do you use?
> pthread_attr_getstack()?

Kind of.  But with one small, but important exception.  pthread_attr_getstack()
returns stackaddr and stacksize values from pthread_attr structure associated
with thread.  But in case if you call pthread_create() with default
attribute then stackaddr will be NULL.  In this case libc_r will allocate
stack for this thread internally and will not export this stack pointer
address into application.  Usually there's no need to do it -- if application
want to know location of thread stack it simply mallocs it and provide
its address via pthread_attr structure to pthread_create().  Initially I
did it in way just described, but lately I found that JVM does not
provide way to deallocate stack after thread finishes.  I had to implement
own deallocating schema via separate thread almost line-by-line similar
to libc_r's gc thread.  Another issue with this way -- JVM provides some
restriction of amount of memory to be used (via command line switches) and
in case if this value was too small -- thread stack were able to eat all
available memory for application itself.  Of course it was possible to
implement it in another way and don't eat applications' memory, but it
was even more hackish than described in first item.

So, implementation of pthread_attr_get_np() with current behavior allowed
me to avoid implementing these hack "solutions".

> > Sorry for not saying anything helpful for you :(
> 
> Not at all, this is very helpful.
> 
> Nick Barnes
> Ravenbrook Limited

-- 
/* Alexey Zelkin             && Independent Contractor      */
/* phantom(at)FreeBSD.org    && http://www.FreeBSD.org/java */
/* phantom(at)cris.net       && http://www.FreeBSD.org.ua/  */