On 11/07/11 10:31, Danek Duvall wrote:
Ali Bahrami wrote:
I bet it has something to do with the X consolidation
switching to delivering 64-bit objects as the default:
% file /usr/bin/xclock
/usr/bin/xclock: ELF 64-bit LSB executable AMD64 Version 1 [SSE2
SSE FXSR CMOV FPU], dynamically linked, not stripped,
Thank goodness -- xclock kept having performance problems due to register
pressure, and now that won't be a problem anymore!
And even better, your clock won't rollback to 1902 when the 32-bit time_t
overflows. (Though 7086868 & 7086762 do show that oclock had some surprising
register usage issues uncovered by this conversion.)
More seriously, I changed the default for all the X apps (though set it back to
32-bit for a few) partially for the amd64 performance benefits and partially as
test cases to help us better test the 64-bit environment and uncover issues
there - few of the classic X apps are that critical (most have more modern &
usable replacements delivered in gnome), but they do get enough use that we
hope to get some amount of testing out of them - and it's better to find issues
like the above mentioned ones on oclock than waiting until they break something
that is more critical.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
