Friday Mar 03, 2006

Neither fish nor fowl - v8plus

A very well kept secret(?) is finally found - I've been wondering for a looooooong time where the heck is the public documentation on v8plus, and it turns out it's very well hidden here.

We're working on making this more easily accessible but in the mean time, the above URL should work. If it doesn't, go to and search for 802-7447.

BTW, if you have no idea what is v8plus, it's an extension of 32bit ABI that is compatible with the old 32bit ABI but allows the use of 64bit processor features. For more detail, you need to look at SPARC ABI specifications called "SPARC Compliance Definition" at the SPARC International resources page.

PS. Many thanks to Steve, Tunji and Chris.

Thursday Mar 02, 2006

GCC for SPARC Systems released!

Do you use gcc on Solaris/SPARC ? Whether you're using it by choice or you're forced to use it due to other reasons, if the answer is yes, here's something you may want to try - GCC for SPARC Systems.

Tuesday Dec 06, 2005

My special thanks to HP for helping Niagara message out.

I've been quite busy with lots of exciting stuff, so I just couldn't pay enough attention to posting a new blog. But I can't just stay quiet upon reading this one from HP.

I'd like to express my deep and sincere gratitude to HP PR folks. Thank you guys for helping the Niagara message out. Thanks for letting HP customers know that there's such a thing as Niagara.

PS. Many thanks to The Inquirer for a nice head-up!
PS2. For those of you who wants to know more about Niagara and what the heck HP is talking about, our own McDougal's blog is a pretty good place to start.

Friday Jul 15, 2005

How to reorder the code to improve the performance

Is your application huge ? A couple of tens of megabytes executables and shared objects ? Then I bet your application would benefit from the code reordering (or sometimes called the instruction cache optimization). A new article posted at has a very graphical illustration of the effect of the code reordering and how to use the compiler to do that. Sun's top ISVs use those options to build their applications. And chances are, your application may benefit as well.

Tuesday Jul 05, 2005

Interface stability and fixed configurations

It's a little dated but still very interesting interview with Tim Marsland (our CTO of Solaris) at ACM Queue. I found the following quote very insightful:

Fixed configurations are really a Band-Aid for unstable inter-component interfaces.
When you look at our experience inside Solaris, 
the reason for what works with what is really about interface stability, or lack thereof. 

Monday Jun 06, 2005

MacOS X on Solaris ?

Our COO invited Apple to adopt Solaris as the base of MacOS X. For those of you who don't remember or know the history behind this, this isn't the first time there's such a proposal. See our own Rich B's blog here for a bit of history. In fact, OpenSTEP implementation was working (including albeit with fonts rendered ugly compared to native NeXTSTEP). FYI, our COO used to work for a company called Lighthouse Design which used to produce softwares for NeXTSTEP.

I used to run NeXTSTEP 3.3j on my SPARCstation, as well as the earlier versions of OpenSTEP on Solaris. All NeXTSTEP GUI applications were great - it indeed was 10 years ahead of everything. However, mach kernel and BSD server in NeXTSTEP best flaky and slow and it was clearly behind Solaris at the time. I think it will take years for darwin to catch up with Solaris 10 - evidence ? OS X has very recently added 64bit support or fine grained locking/reentrant kernel and it's been years since Solaris had those. And it will take even more time for Apple to catch up with all those new features in Solaris 10 - Dtrace, Zones, ZFS, FMA and etc. IMHO, it would make perfect sense for Apple to switch to Solaris 10 on x86 replacing Darwin. Here's hoping that Apple will consider switching to Solaris :)

PS. I know. It's even less likely than Apple's switch to Intel. But surely one can have a dream.

Monday Apr 25, 2005

Be careful with unlimited stack (or why my 32bit app can not use more than 2GB of memory)

Once in a while, this same question pops up on some of the mailing lists. Usually it's about some 32bit application trying to use more than 2GB of memory, or address space, to be exact. And the application mysteriously can not get past 2GB marker for no apparent reason - the system has plenty of memory and enough free swap space, and 64bit programs work just fine.

I've seen various reasons for this, like a bug in malloc() in libc for example. But by far the most common reason was due to unlimited stack size.

On Solaris, if you set the stack size to unlimited, your heap can not grow past 2GB. That's because the kernel reserves upper 2GB for stack usage. IMHO, this "unlimited" is a little misleading, since it actually means the maximum stack size is 2GB.

The kernel has to put a guard page (or pages?) at the end of the ulimit-specified maximum stack size, so that the overflow of the stack can be detected as well as interim pages are mapped on demand. This means that essentially ulimit-specified stack sized address space is always reserved for stack use.

Following code shows what's going on:

# cat t.c

    pid_t pid;
    int \*p = (int\*)(0xff000000);

    \*p = 0;
    pid = getpid();
    char buf[100];
    sprintf(buf, "pmap %d\\n", pid);
    return 0;
# cc -g t.c
# ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) unlimited
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29995
virtual memory        (kbytes, -v) unlimited
# ./a.out
11267:  ./a.out
00010000       8K r-x--  /home/seongbae/tmp/a.out
00020000       8K rwx--  /home/seongbae/tmp/a.out
7FA80000     848K r-x--  /lib/
7FB64000      32K rwx--  /lib/
7FB6C000       8K rwx--  /lib/
7FB8A000       8K rwxs-    [ anon ]
7FB90000       8K r-x--  /platform/sun4u-us3/lib/
7FBA0000      24K rwx--    [ anon ]
7FBB0000     176K r-x--  /lib/
7FBEC000       8K rwx--  /lib/
7FBEE000       8K rwx--  /lib/
FF000000   12288K rwx--    [ stack ]
 total     13424K
# ulimit -s 10240
# ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 10240
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29995
virtual memory        (kbytes, -v) unlimited
# ./a.out
Segmentation Fault (core dumped)
# dbx ./a.out
Reading a.out
(dbx 1) r
Running: a.out 
(process id 11275)
signal SEGV (no mapping at the fault address) in main at line 11 in file "t.c"
   11       \*p = 0;
(dbx 2) p p
p = 0xff000000
(dbx 3) quit

Thursday Dec 23, 2004

Virtual scrolling works on Solaris 10...

Now I'm one step closer to my computing nervana, thanks to Casper. His new Xorg mouse driver for touchpad supports vertical and horizontal virtual scrolling as well as 4-way middle button. Now if only Solaris 10 supports suspend-resume on x86 (I heard something's coming in this area..) it would be nearly perfect...



« July 2016