harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Date Wed, 18 Apr 2007 07:44:38 GMT
On 4/18/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 4/18/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> >
> > On 4/17/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > On 4/18/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> > > >
> > > > Mikhail,
> > > >    I have no problem with the ones you updated, but some questions...
> > > >
> > > > Is VM_RT_WRITE_BARRIER_FASTCALL in use?
> > >
> > >
> > > This helper is dead code  today. AFAIR gcv5 uses VM_RT_GC_HEAP_WRITE_REF
> > > today.
> >
> > OK thanks. We need to get rid of the dead gcv4 code. This is probably
> > what refers to the old barrier helper.
> > >
> > > And are the monitor enter/exit functions all interruptible?
> > > >
> > >
> > > I think monenter is must be. Thread can stall for a long period of time
> > on
> > > monenter. And I do not know if monexit is. At least it can throw
> > > IllegalState-like exception in theory.
> >
> > Yes right, both throw exceptions like nullpointer, illegalmonitorstate
> > etc. But these are supposed to be thrown lazily.
> >
>
> Actually I have never seen an exception thrown from monexit. JIT generates
> endless loop for an exception thrown from monexit and never let it go until
> monexit is called without exceptions.

 Is this the case? If monitorExit meets a lock that is owned by other
thread, it has no way to exit but to throw an exception.

> --
> Mikhail Fursov
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message