Re[2]: [Gc] gcj 4.6 on OpenBSD/x86

Ivan Maidanski ivmai at mail.ru
Sat Jun 8 07:48:26 PDT 2013


 Hi Kurt,

I've applied your patch to master with some adjustments; see the commits:
*  https://github.com/ivmai/bdwgc/commit/a233df5a38a8b1180b31285f005153f5c337e145
*  https://github.com/ivmai/bdwgc/commit/b2a030e0db5e0d53b660a8d2c6615274bb8b375b
*  https://github.com/ivmai/bdwgc/commit/012d17d56c985d0501fffd16eb606470e0c7e0ce
*  https://github.com/ivmai/bdwgc/commit/55b6a0870003cc72864a7168311605c71bd874c8

Please retest it.
Thank you

Regards,
Ivan

Sat,  1 Jun 2013, 11:55 -04:00 from Kurt Miller <kurt at intricatesoftware.com>:
>Hi Ivan,
>
>Please see replies inline below.
>
>On 06/01/13 04:35, Ivan Maidanski wrote:
>> Hi Kurt,
>> 
>> 1. One thing is unclear to me (from the patch): OpenBSD provides (or
>> provided) nice way to suspend/getstate/resume threads, your patch
>> disables it (for recent OpenBSD) in favor of emulation of these
>> operations via signals which has drawbacks (like hard-coding signal
>> numbers, etc.) but inevitable on most pthread-based platforms. What's
>> the reason?
>
>When we implemented kernel supported threads on OpenBSD (aka rthreads)
>we considered implementing pthread_suspend_np however we decided against
>it. There were two main application users of these non-portable
>functions: boehm-gc and OpenJDK perhaps also mono. Under our previous
>thread library, uthreads, we emulated threading and didn't have kernel
>backed threads. For boehm-gc I used pthread_suspend_np but it needed the
>current stack pointer for which we didn't have a function for, so I
>wrote a rather gross hack that offset into the private pthread structure
>and obtained it that way. So when we looked at what to do for rthreads
>we decided that using signals was more portable then introducing another
>non portable pthread function to obtain the stack pointer for the
>suspended process. We removed all use of pthread_suspend_np and related
>functions from our ports tree at the time we cut over to rthreads and
>bumped major version number on libpthread.so.
>
>> 2. There are 2 independent part in your patch: first is for dyn_load.c
>> and for the rest, right? (if yes, I'll break it into to commits)
>
>Yes that is correct. Oh, I noticed that I repeated the define for
>HAVE_DL_ITERATE_PHDR. Corrected diff attached.
>
>> 
>> 3. Reason of adding include <sys/param.h> to gc_config_macros.h is to
>> define OpenBSD, right?
>
>Yes, that gets us the OpenBSD define which is the year and month of the
>release.
>
>> 4. Some commit message is highly appreciated
>
>- Add support for rthreads (kernel supported threads) introduced OpenBSD
>5.2 and higher. Maintain support for older releases using uthreads on
>OpenBSD as well.
>
>> 5. I don't think we should apply to 7.2d (this seems to be not a fix)
>
>Right. I'm mostly concerned with getting this included upstream for
>future releases. I have a patched 7.2d about to be committed to our
>ports tree.
>
>> The rest looks good (I haven't tested it on OpenBSD though).
>
>Thank you for your review.
>
>Regards,
>-Kurt
>
>> Regards,
>> Ivan
>> 
>> Fri, 31 May 2013, 15:30 -04:00 from Kurt Miller
>> < kurt at intricatesoftware.com >:
>> 
>>     Hi Ivan,
>> 
>>     Sorry about the long delay. Attached please find a diff that update's
>>     OpenBSD's support to handle our kernel based threads since 5.2 release
>>     and maintains the prior user-land threads code for pre 5.2.
>> 
>>     A similar diff for 7.2d has been tested on the following OpenBSD
>>     architectures: i386, amd64, sparc64, macppc, hppa, alpha.
>> 
>>     Please consider incorporating this diff into your git repository.
>> 
>>     Thank you,
>>     -Kurt
>
>
>_______________________________________________
>Gc mailing list
>Gc at linux.hpl.hp.com
>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/


-- 
Иван Майданский
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130608/6f92d586/attachment.htm


More information about the Gc mailing list