harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][sablevm] Desing of Class Unloading Support
Date Wed, 01 Nov 2006 10:46:42 GMT
On 01 Nov 2006 16:05:41 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
> > On 01 Nov 2006 15:56:28 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> > >
> > > agreed. not patching .. just reporting 'golden' VTable refs to GC, am
> > > I right?
> > >
> > Yes, and everytime we report it to GC and GC moves an object - it
> patches
> > the address we report.
>
> so, by saying "patching" you insist to put immediate operands into
> instructions? That's probably worth it, but it extends the JIT<->GC
> interface. How about making a simple operand (reg/mem) as the first step?


Egor, I thinks this is slightly more complicated problem. If vtable object
is moved we must update all devirtualization points in every method compiled
before. It can require an extension of JIT<->VM<->GC interface.
Another solution I see is to collect info about all devirtualization points
in JIT (code addrs) and report these addresses as enumeration roots. This is
JIT-only solution, and disadvantage is a significant (~hot methods count)
increase of number of objects reported.

On the other hand I see no reasons to unpin vtables in the nearest future
(Let's GC guru correct me). If you use special (freelist-type ?) allocator
in GC the memory fragmentation when unloading pinned vtable objects could be
low.

-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message