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
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-ch
On Tue, Nov 3, 2009 at 7:11 PM, kirk wrote:
>
>
>
> 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 guarant
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 i
Then maybe the spec is where the flaw is...
Sent from my iPhone
On Nov 3, 2009, at 10:45 AM, Marcelo Fukushima
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 an
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 wrote:
>
> I just don't think that it's a good idea
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 spe
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 may
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?
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'
2009/11/3 Stuart McCulloch
> 2009/11/2 Brent
>
>>
>> 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 it
2009/11/2 Brent
>
> 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 b
Brent wrote:
> 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
> ea
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, bu
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 de
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?
I know what the SUN bug said, but I disagree that it's not a flaw. At
the very least, they should have provided a JVM argument that allowed
you
Hello,
yes. synchronized doesn't use fair locking.
Hum. I have a doubt about "Stat" thread. The run method doesn't use
any kind of synchronization to read shared "stats" array. Is there a
guarantee that the values it prints out is not stale? Me. I wouldn't
say that.
Well. On my Quad Core linux
2009/11/2 Brent
>
> I was curious... How many people have run into this bug that was
> introduced with JDK 5?
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316090
>
> We've recently run into this issue and I was actually a little shocked
> to find out that the JVM behaved like this. Ba
18 matches
Mail list logo
