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 >>> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
