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.
v.
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
