<div class="moz-text-flowed" style="font-family: -moz-fixed"> Marcelo Fukushima wrote: > i should probably write in a better way (i guess i cant write in > english as well as i can read) > > what i meant was that os thread could potentially behave like how java > threads behave: there are not guarantees that any given thread will be > given its timeslice in the CPU. In that regard, the jvm spec is not > 'broken', like it was implied, but rather mimic what native threads do > (or potentially do) > the jvm spec *cannot* say anything about native threads because that behavior is outside of the box. > and regarding biased locking, my guess was that some threads were > starving because of lock biasing: the thread that previously had the > lock always gets the lock before the other threads (in that small > example, inside the doSomething method). But that is just a guess, not > having even ran the code. > biased locking doesn't work that way. a lock will be biased to a thread until another thread requests it. Then the biases are revoked and threads are on their own competing for the lock.
IMHO, guessing at a performance bug is never a good idea. I'd suggest you grab a copy of yourkit (or another like profiler) and run the app under some expected load. A good thread profiler will let you know if there is a problem. Regards, Kirk > On Tue, Nov 3, 2009 at 6:27 PM, kirk <[email protected]> wrote: > >> Marcelo Fukushima wrote: >> >>> 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 >>> >>> >> I maybe jumping in the middle here as I've not been closely following >> this thread. >> >> 1) Native threads are under the control of the OS. This lies outside of >> what Java has any control over. >> 2) I'm not sure what biased locking has to do with thread scheduling. A >> thread maybe biased to a lock/monitor. Biasing happens as a result of >> HotSpot recognizing that only one thread is acquiring a monitor and then >> biases the lease to that monitor to that thread. If another thread >> requests that monitor, the bias is revoked. Once revoked it can never be >> rebiased under the current implementation. >> >> Regards, >> Kirk >> >> >>> 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 >>>>> >>>>> >>>>> >>> >>> >>> >> > > > > </div> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
