Then maybe the spec is where the flaw is... Sent from my iPhone
On Nov 3, 2009, at 10:45 AM, Marcelo Fukushima <[email protected]> wrote: > > i guess what reinier was trying to say was that your code (as far as > vm spec goes) was broken from the start and (again, from the vm spec > perspective) lucky timing and scheduling just made it work correctly > > On Tue, Nov 3, 2009 at 3:26 PM, Brent <[email protected]> wrote: >> >> I just don't think that it's a good idea to say...Let's break >> something so that we can optimize the JVM for most cases without >> providing an option that allows the JVM to execute threads one way >> vs. >> another. This used to work in JDK 1.4. >> >> Does anyone know how .NET solves this problem with the CLR? >> >> >> >> On Nov 3, 1:52 am, Reinier Zwitserloot <[email protected]> wrote: >>> 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 >>> >> > > > > -- > http://mapsdev.blogspot.com/ > Marcelo Takeshi Fukushima > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
