well one could argue that, though im not sure if native threads have such guarantee - in which case, java may only be delegating to native
that said, you can try disabling biased locking (starting from java 6 i think) and see if it makes any difference On Tue, Nov 3, 2009 at 5:40 PM, Brent Ryan <[email protected]> wrote: > > 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 >> >> > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
