GC updates for 64-bit Darwin 8/OSX 10.4

This patch should fix darwin_stop_world.c for 64-bit Darwin/OSX. It  
is also compatible with 32-bit with no code changes. I haven't tested  
it yet, not having a G5 handy, but according to Apple's developer  
docs, it should work.

Andrew

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

Resurrecting pointers

Hi,

I would like to know if it is possible to reattach a finalization
function to an object that has been resurrected during finalization. If
it is not, would it be hard/unsafe to adapt the GC to do this ?

Thanks a lot !

Regards,

Guilhem Lavaux.

Re: Resurrecting pointers

Just registering it again in the finalizer should work fine,
as it stands.

I know of no way to access this functionality from Java though.
But there are less direct ways to accomplish something similar.

Hans

On Sun, 1 May 2005, Guilhem Lavaux wrote:

> Hi,
>
> I would like to know if it is possible to reattach a finalization
> function to an object that has been resurrected during finalization. If
> it is not, would it be hard/unsafe to adapt the GC to do this ?
>
> Thanks a lot !
>
> Regards,
>
> Guilhem Lavaux.
>
> _______________________________________________
> Gc mailing list
> Gc@...
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>

Using the Boehm-Demers-Weiser GC with a new threading library

Hello,

I am developing a threading library, and wish to make it work with your GC. As I 
understand this may very well not be trivial, and by no means would I ask you to 
work on this task, I thought at least I could ask you for some information as to 
how I should proceed.
I have two aspects in my threading library:
- The first one is cooperative threads, implemented in C via copying of the 
stack, and setjmp/longjmp. Every new thread saves its stack and setjmp result in 
the heap before cooperating to another thread by restoring its stack and doing a 
longjmp. If I'm not clear here, I can probably explain better, but I'm sure this 
is rather common.
- The second one is that I want my threads to be able to become asynchronous, 
and this is done in a rather complicated way involving pthreads. Every thread 
starts as cooperative. If I want a thread that can become asynchronous, I have 
to specify it when I create it. If this is the case, then I have to create a 
pthread in order to get a new stack (this is where it really differs from GNU 
PTH). This is where it gets fishy. The new pthread will do nothing and wait on a 
condition variable. Then the main thread (the one which was doing stack copies 
and setjmp, scheduling cooperative threads) schedules that new thread by doing a 
longjmp back and forth from it, just like "plain" cooperative threads. If that 
threads wishes to become asynchronous, it saves its stack, jumps to the next 
cooperative thread (the main thread), which then wakes up the PThread, which in 
turn will restore the saved stack and longjump to where it was when it was 
cooperative. Still there?
If I try to rephrase this: I'm using pthreads for creating a stack. My main 
thread jumps back and forth from/to any thread/pthread's stack. And if a thread 
wants to become asynchronous, we save it, restore the stack which was doing a 
pthread_cond_wait, wake it up, and let it jump to where we saved it.
This is rather complex, and perhaps suboptimal compared to executing pthreads 

Re: Resurrecting pointers

Thanks. I had some doubts because I was doing something wrong at the
same time with atomic mallocs. It seems to work now.

Guilhem.

On Sun, 2005-05-01 at 11:05 -0700, Hans Boehm wrote:
> Just registering it again in the finalizer should work fine,
> as it stands.
> 
> I know of no way to access this functionality from Java though.
> But there are less direct ways to accomplish something similar.
> 
> Hans
> 
> On Sun, 1 May 2005, Guilhem Lavaux wrote:
> 
> > Hi,
> >
> > I would like to know if it is possible to reattach a finalization
> > function to an object that has been resurrected during finalization. If
> > it is not, would it be hard/unsafe to adapt the GC to do this ?
> >
> > Thanks a lot !
> >
> > Regards,
> >
> > Guilhem Lavaux.
> >
> > _______________________________________________
> > Gc mailing list

Preserving the value of errno.

Hello,

    We noticed that the value of errno was being clobbered using libgc
in Mono, the following patch fixes the problem.

    The error was hard to reproduce and it meant that an ENOENT was
being mapped into an EINTR.

Miguel.
--

-- 
Miguel de Icaza <miguel@...>

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

Re: Using the Boehm-Demers-Weiser GC with a new threading library

Stephane Epardaud wrote:
> Hello,
> 
> I am developing a threading library, and wish to make it work with your 
> GC. As I understand this may very well not be trivial, and by no means 
> would I ask you to work on this task, I thought at least I could ask you 
> for some information as to how I should proceed.
<snip>
> I've looked a bit at the linux_threads.c file in your GC, and it looks 
> very clear and documented. The only thing it seems I would have to do in 
> the end is to restrict the GC scanning of parts of some GC_malloc'ed 
> blocks. But maybe I'm completely missing something ?

The GC calls the thread support module to find stacks, so you can 
allocate the cooperative thread stacks with GC_malloc_atomic and then 
control which parts are actually scanned by modifying the thread support 
functions.

The interface that each thread support module provides to the collector is:

/* Push all potential heap pointers on all thread stacks onto the   */
/* mark stack.                                                      */
void GC_push_all_stacks(void);
/* Push any potential heap pointers used by the thread support code */
/* that aren't members of the root set onto the mark stack.         */
void GC_push_thread_structures(void);
/* Suspend all heap-using threads other than the current thread     */
/* (and block creation of more heap-using threads).                 */
void GC_stop_world(void);
/* Resume all suspended heap-using threads.                         */

RE: Preserving the value of errno.

Miguel -

Thanks for tracking this down.

I won't quite use your patch, since things changed around there
in 6.5.  But I did add code to save and restore errno in
suspend_handler.

Do you have reason to believe that this is needed in restart_handler?
I believe it shouldn't, since that should only be delivered to a thread
currently executing in the suspend_handler, and thus suspend_handler
should
already restore the correct errno.

Hans

> -----Original Message-----
> From: gc-bounces@... 
> [mailto:gc-bounces@...] On Behalf Of Miguel de Icaza
> Sent: Monday, May 02, 2005 4:11 PM
> To: gc@...
> Subject: [Gc] Preserving the value of errno.
> 
> 
> Hello,
> 
>     We noticed that the value of errno was being clobbered 
> using libgc in Mono, the following patch fixes the problem.
> 
>     The error was hard to reproduce and it meant that an 

RE: Preserving the value of errno.

Hey,

> I won't quite use your patch, since things changed around there
> in 6.5.  But I did add code to save and restore errno in
> suspend_handler.
> 
> Do you have reason to believe that this is needed in restart_handler?
> I believe it shouldn't, since that should only be delivered to a thread
> currently executing in the suspend_handler, and thus suspend_handler
> should already restore the correct errno.

We wrote a test case to reproduce the issue with one of the signals, and
once we found that this was the problem, I decided to play it safe and
just make sure that errno was not going to be overwritten.

I did not look deeper than that, so you might be right 

Miguel.

Re: Using the Boehm-Demers-Weiser GC with a new threading library

Ben Hutchings wrote:
 > <snip>
> If you start from the linux_threads implementation I think you'll only 
> need to change GC_push_all_stacks.  Use GC_push_all to push the active 
> part of each cooperative thread stack on the mark stack.

Hi,

Thanks a lot, I'm looking into it right now, but I have two questions:
- Why does the linux_thread module need to push the GC_threads array on
   the mark stack in GC_push_thread_structures() ? Is is because it is declared
   as volatile ? I'm not sure what volatile means, but I thought the GC could
   scan global variables (such as GC_threads), so I fail to see why I would need
   to put anything in GC_push_thread_structures() ...
- If I use GC_push_all to push the active part of each cooperative thread
   stack on the mark stack as you suggest, will that prevent the GC from looking
   at the non-active part of that cooperative thread stack (since the stack in
   question was allocated with GC_malloc, and I'm sure the GC will find a way to
   that stack from either a root or a global variable) ? If not, is the correct
   solution to allocated these roots via normal malloc and use GC_push_all, or
   rather to keeping using GC_malloc and use GC_exclude_≤something> to restrict
   the scanning to the active part of the scan ?