Vladimir Kotal wrote:
Keith McGuigan wrote:
<snip>
This the JVM and it generates a lot of code on the fly. If we can be
assured that we will never run in SMP mode, then there are
optimizations we perform (skipping, certain locking, etc.). Right
now we check _CONFIG_NPROC_CONF when the VM starts and if it returns
1 was perform these optimizations. If another CPU comes online
somehow (via a resource pool), then we're in trouble since we've
generated a bunch of invalid code.
I've never seen this happen, but I'm investigating a bug in which I
strongly suspect that this is the case. The crashes match what would
happen and the core file shows that we did find only 1 processor at
startup time. In this case the VM was running in a zone configured
with "dedicated-cpu: ncpus 1-2" (though I don't know enough about
zones to know what that means). Of course whenever I log into that
zone I find 2 processors no problem so I can't reproduce the error.
Using MAX instead of CONF may end up disabling some of these
optimizations when running an a zone with 1 dedicated cpu, but really
these optimizations are targeted for uniprocessor client systems. So
I suspect MAX may work out ok and solve this problem.
(Not sure if you wanted all the background, but you get it for free
anyway) :)
By using MAX you will end up not doing the optimizations at all on
most of todays (non-embedded (sic!)) systems.
The background of the non-SMP condition above is still not entirely
clear to me but you might want to look at processor_bind(2) syscall
(which is not present on every UNIX system) to see if it can help you.
In my opinion, in today's world, optimizations for uniprocessor mode
probably shouldn't be made by applications. Applications should just
call the appropriate library functions (mutex_lock, etc.) and assume
that they are on SMP systems.
The system should supply an optimized version of mutex_enter that works
properly in the face of uniprocessor systems... however in the face of
true threading libraries with multiple LWPs per application, I don't
think you can elide away the calls to mutex_enter.
Anyway, more and more, the uniprocessor case is becoming the exception
rather than the rule... even in the embedded arena I think the trend is
towards multiple cores or multiple threads of execution on a single CPU.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
