Why does java not guarantee gc()? Why does java not do a lot of things? Because it would severely cramp the optimizer.
Adding your proposed rule across the board would probably put a serious dent in the optimization work the hotspot compiler can do to your code. Same reason why finalizers aren't guaranteed. Same reason gc () isn't. There's a perfectly workable way out of this - use the right code construct. Such as fair locks. What interests me in particular is that you've evidently got significantly more work for your CPU than your CPU has cycles to do that work in, or you shouldn't be running into big issues. Presumably, then, some threads are tilting at windmills, calculating endlessly. This is par for the course if your app has a definitive start and end, such as, say, an unzip application, but most complex apps end up being a server that handles requests - which leads me to wonder: Perhaps you should be adding some sort of queueing system to your app, or more on- demand processing. On Nov 2, 5:29 pm, Stuart McCulloch <[email protected]> wrote: > 2009/11/3 Stuart McCulloch <[email protected]> > > > > > > > 2009/11/2 Brent <[email protected]> > > >> But why does the JVM have to know my intent... It knows that I > >> started a thread and it knows that it has some priority. So why can't > >> it just stick all of the threads that were started for a particular > >> priority on a queue and then iterate through that queue. It might be > >> easier said then done, but that's what I don't understand. > > >> Example: > > >> If you have 3 threads with same priority... > > >> Thread 1 (default priority 5) > >> Thread 2 (default priority 5) > >> Thread 3 (default priority 5) > > >> Let's pretend that each thread executes 2 loops. > > >> Execute Thread 1 > >> Execute Thread 2 > >> Execute Thread 3 > >> Execute Thread 1 > >> Execute Thread 2 > >> Execute Thread 3 > > >> If the threads have different priorities then this wouldn't work, but > >> assuming that they have the same priority why doesn't the JVM do > >> this? Can you dumb it down for me more? > > > does this comparison help? > > > updates to fields in Java are not specified to be atomic > > => use synchronization to guarantee atomic updates > > > scheduling order of threads on Java locks is not defined > > => use "fair" locking to guarantee scheduling fairness > > > ie. you should not rely on behavior that is not specified. > > I don't say this is easy - avoiding this is a hard problem, > > especially when there's few alternative implementations > > that you can run tests on > > > I've seen a lot of customer code that relied on unspec'd > > behavior all over the JDK - including one who was using > > mutable keys in a hash map (which is not good at all!) > > and expected it to work a very specific way :( > > > We experienced this issue running Weblogic 9.2 container and the > >> thread scheduling isn't even available to us since it's a EE container > >> and you're not suppose to manage threads. Ultimately, what you're > >> telling me is that weblogic has a bug and that they should have used > >> java.util.concurrent. > > > I haven't seen your app code, so I can't really comment. > > > If you're pushing the container provided threads through > > basic (non-fair) locks then you might need to switch to > > use fair locking - if the container is the only one doing > > the locking then they probably have a bug. > > also I should say that scheduling is a hard problem, > and policies that guarantee no starvation often have > downsides in other areas (eg. response/throughput) > > http://en.wikipedia.org/wiki/Scheduling_%28computing%29#Overview > > otherwise why would the HotSpot 1.5 JVM suddenly > change their lock ordering - it must have had benefits > elsewhere, I doubt they did it just to annoy people! > > > > > > > On Nov 2, 9:53 am, Phil <[email protected]> wrote: > >> > I think you're missing the point. The JVM can't know your intent when > >> > you started your threads and cannot know that the right thing to do is > >> > to 'level' resource usage across your threads. If you need your > >> > threads to receive a more equal share of resources then this needs to > >> > be expressed in your design. Hence the suggestion to use fair locks to > >> > more precisely influence the scheduler. > > >> > Even the thread priority is not a hard and fast guarantee, just an > >> > indication (or to quote a pirate: the code is more what you'd call > >> > "guidelines" than actual rules). If you read a good Java certification > >> > textbook it will tell you threads must have priorities, and that the > >> > priority can be between 1 and 10, but it does not dictate what the JVM > >> > should do about these different priorities. In general, scheduling > >> > algorithms are left to the implementor, about the only thing you can > >> > be certain of is that 1 is viewed as the lowest priority, 10 as the > >> > highest and 5 as the default. Beyond that, all bets are off. > > >> > Phil. > > >> > On Nov 2, 2:32 pm, Brent <[email protected]> wrote: > > >> > > How does that look ok to you? Threads 0 and 1 only executed 23 times > >> > > while the other threads executed 45/46 times. How can that ever be a > >> > > good thing? > > > -- > > Cheers, Stuart > > -- > Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
