On 7/16/2012 1:45 PM, Barrett, Brian W wrote:
> It's unlikely that I will have time to fix this in the short term. The
> scheduling code is fairly localized in nbc.c if Oracle has some time to
> spend looking at these issues. If not, it might be best to remove the
> libnbc code from 1.7, as it's unfortunately clear that it's not as ready
> for integration as we believed
Or both! That is, I agree the code looks manageable and I'm inclined to
take a whack at it. Nevertheless, the NBC stuff in v1.7 is in a painful
state. Without CMRs, it does perhaps more harm than good.
> and I don't have time to fix the code base.
> On 7/16/12 2:50 PM, "Eugene Loh"<eugene.loh_at_[hidden]> wrote:
>> The NBC functionality doesn't fare very well on SPARC. One of the
>> problems is with data alignment. An NBC schedule is a number of
>> variously sized fields laid out contiguously in linear memory (e.g.,
>> see nbc_internal.h or nbc.c) and words don't have much natural
>> alignment. On SPARC, the "default" (for some definition of that word)
>> is to sigbus when a word is not properly aligned. In any case (even
>> non-SPARC), one might argue misalignment and subsequent exception
>> handling is nice to avoid.
>> Here are two specific issues.
>> *) Schedule layout uses single-char delimiters between "round
>> schedules". So, even if the first "round schedule" has nice alignment,
>> the second will have single-byte offsets for its components.
>> *) 8-byte pointers can fall on 4-byte boundaries. E.g., say a schedule
>> starts on some "nice" alignment. The first words of the schedule will be:
>> int total size of the schedule
>> int number of elements in the first round schedule
>> enum type of function
>> void * pointer to some buffer
>> So, with -m64, that 8-byte pointer is on a 12-byte boundary.
>> Any input/comments on how to proceed?
>> devel mailing list