On Tue, Nov 3, 2009 at 7:11 PM, kirk <kirk.pepperd...@gmail.com> wrote: > > > <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.
of course not, but that was not what i was saying at all... what i was trying to say was that jvm spec might just mimic what OS's do - and they are not broken in that aspect. >> 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. youre totally right here, although strictly speaking it was not about performance, but rather about how threads behave and/or are allowed to behave according to the spec but i was completely wrong about lock biasing > > Regards, > Kirk >> On Tue, Nov 3, 2009 at 6:27 PM, kirk <kirk.pepperd...@gmail.com> 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 <brent.r...@gmail.com> wrote: >>>> >>>> >>>>> Then maybe the spec is where the flaw is... >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Nov 3, 2009, at 10:45 AM, Marcelo Fukushima <takesh...@gmail.com> >>>>> 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 <brent.r...@gmail.com> 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 <reini...@gmail.com> 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 <mccu...@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2009/11/3 Stuart McCulloch <mccu...@gmail.com> >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2009/11/2 Brent <brent.r...@gmail.com> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 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 <p...@haigh-family.com> 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 <brent.r...@gmail.com> 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> > > > > > -- 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
