[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    review request for 6699669
From:       Karen.Kinnear () Sun ! COM (Karen Kinnear)
Date:       2009-03-30 20:04:09
Message-ID: 49D125B9.2000000 () sun ! com
[Download RAW message or body]

Xiaobin,

This actually looks less risky than the current code.

Would it make sense to run some of our bigger apps that stress
synchronization, contention and inflation? Like volano?
Dave Dice has PointBase and could probably recommend the best
other tests that would benefit from a several day stress run?

thanks,
Karen

Xiaobin Lu wrote:
> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6699669/
> 
> Details:
> 
> Currently, we use a field called "_highest_lock" in the Thread structure 
> to keep track of the highest possible lock address so that we can tell 
> whether an given lock address belongs to the current thread. The field 
> gets updated whenever the thread acquires a lock. It turns out in some 
> cases, for example, after the interpreted frames are replaced by the 
> compiled frames, the _highest_lock field might not get updated correctly 
> and as a result, Thread::is_lock_owned could return false even the 
> thread owns the lock since that method relies on the correctness of the 
> _highest_lock.
> 
> It turns out that we could completely get rid of the use of 
> _highest_lock and solely rely on _stack_base and _stack_size recorded in 
> the Thread structure to tell whether a given lock address belongs to the 
> current thread. And that is exactly what I am trying to do in the webrev.
> 
> Reviewed by:
> Verified by:
> Two tests from the bug report
> runThese full
> nsk in progress
> 
> Thanks to Tom, Dave & David for the help to understand the issue.
> -Xiaobin



[prev in list] [next in list] [prev in thread] [next in thread]