gcj port to hppa...

[Carlos O'Donell-2]

Dave,

The gcj port to hppa uses a locking implementation
(libjava/sysdeps/pa/locks.h) which is not signal safe.

The assembly can be interrupted by a signal which if it calls
compare_and_swap again will deadlock. However, I can't tell if this
will ever happen.

The fix for this is to port the lock implementation to use the
light-weight in-kernel compare-and-swap, which is thread-safe and
signal-safe. However, this is only available for Linux.

Does locks.h also need to work for HPUX?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> The gcj port to hppa uses a locking implementation
> (libjava/sysdeps/pa/locks.h) which is not signal safe.

Yes.  Is this the gcj problem that you were seeing with nptl?

> The assembly can be interrupted by a signal which if it calls
> compare_and_swap again will deadlock. However, I can't tell if this
> will ever happen.
>
> The fix for this is to port the lock implementation to use the
> light-weight in-kernel compare-and-swap, which is thread-safe and
> signal-safe. However, this is only available for Linux.

I would say the linux implementation should uses the gcc atomic builtins.
They are based on the kernel compare-and-swap.

> Does locks.h also need to work for HPUX?

Yes.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 1:40 PM, John David Anglin
<dave@...> wrote:
>> The gcj port to hppa uses a locking implementation
>> (libjava/sysdeps/pa/locks.h) which is not signal safe.
>
> Yes.  Is this the gcj problem that you were seeing with nptl?

No it is not, but I noticed this during my investigations. I might as
well fix it while I'm poking about.

>> The assembly can be interrupted by a signal which if it calls
>> compare_and_swap again will deadlock. However, I can't tell if this
>> will ever happen.
>>
>> The fix for this is to port the lock implementation to use the
>> light-weight in-kernel compare-and-swap, which is thread-safe and
>> signal-safe. However, this is only available for Linux.
>
> I would say the linux implementation should uses the gcc atomic builtins.
> They are based on the kernel compare-and-swap.

Oh, that's a perefect idea, I wasn't sure that libjava could make use
of those atomic builtins.

Doesn't this restrict the gcc version you can use to rebuild libjava?
Is that OK?

>> Does locks.h also need to work for HPUX?
>
> Yes.

OK, how do I write conditional code for HPUX vs. Linux?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> On Sun, Nov 8, 2009 at 1:40 PM, John David Anglin
> <dave@...> wrote:
> >> The gcj port to hppa uses a locking implementation
> >> (libjava/sysdeps/pa/locks.h) which is not signal safe.
> >
> > Yes. =A0Is this the gcj problem that you were seeing with nptl?
>
> No it is not, but I noticed this during my investigations. I might as
> well fix it while I'm poking about.

There's similar code in libstdc++.

> Oh, that's a perefect idea, I wasn't sure that libjava could make use
> of those atomic builtins.
>
> Doesn't this restrict the gcc version you can use to rebuild libjava?
> Is that OK?

In my opinion, yes.

> >> Does locks.h also need to work for HPUX?
> >
> > Yes.
>
> OK, how do I write conditional code for HPUX vs. Linux?

Check __linux and/or __hpux.  Look at the arm code.  It looks
like they have done this.  So, you should just be able to copy
what they have done.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 1:58 PM, John David Anglin
<dave@...> wrote:

>> On Sun, Nov 8, 2009 at 1:40 PM, John David Anglin
>> <dave@...> wrote:
>> >> The gcj port to hppa uses a locking implementation
>> >> (libjava/sysdeps/pa/locks.h) which is not signal safe.
>> >
>> > Yes. =A0Is this the gcj problem that you were seeing with nptl?
>>
>> No it is not, but I noticed this during my investigations. I might as
>> well fix it while I'm poking about.
>
> There's similar code in libstdc++.

Where? I'll fix that case too.

BTW, the gcj problem looks like a missing _STACK_GROWS_UP case in boehm-gc.

>> Oh, that's a perefect idea, I wasn't sure that libjava could make use
>> of those atomic builtins.
>>
>> Doesn't this restrict the gcc version you can use to rebuild libjava?
>> Is that OK?
>
> In my opinion, yes.

Is that OK?

>> >> Does locks.h also need to work for HPUX?
>> >
>> > Yes.
>>
>> OK, how do I write conditional code for HPUX vs. Linux?
>
> Check __linux and/or __hpux.  Look at the arm code.  It looks
> like they have done this.  So, you should just be able to copy
> what they have done.

Thanks.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> > There's similar code in libstdc++.
>
> Where? I'll fix that case too.

config/cpu/hppa/atomicity.h.  On linux, we probably want to use
config/cpu/generic/atomicity_builtins/atomicity.h.  However, I'm
not sure the current configure checks work correctly for library
implementations.

On hpux, we probably should switch to using
config/cpu/generic/atomicity_mutex/atomicity.h and get rid of the hppa
specific implementation.  Originally, there wasn't any locking in the
generic code.

> BTW, the gcj problem looks like a missing _STACK_GROWS_UP case in boehm-gc.
>
> >> Oh, that's a perefect idea, I wasn't sure that libjava could make use
> >> of those atomic builtins.
> >>
> >> Doesn't this restrict the gcc version you can use to rebuild libjava?
> >> Is that OK?
> >
> > In my opinion, yes.
>
> Is that OK?

I can approve any change that is hppa specific.  There's also a precedent
in the arm implementation.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...