Yes, I was indeed saying that java didn't break anything. your app was broken from the start by relying on something that isn't in the spec.
Every release of the JVM *breaks* lots of things you shouldn't have relied upon, every time it updates, especially around the topic of threading. double-checked locking used to work. It doesn't any more, for example. On Nov 3, 9:44 pm, Marcelo Fukushima <[email protected]> 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) > > 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. > > > > > > 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 > > --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 -~----------~----~----~----~------~----~------~--~---
