harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM] 64-bit support with compressed pointer
Date Fri, 02 Feb 2007 21:47:42 GMT
Yes, gc_cc has a hardcoded compressed pointers support. Adding dynamic
switching between compressed and uncompressed pointers is somewhere in
my todo list. I can make the changes if we going to go this way.

There is also some code in interpreter which compresses references in
interpreter stack. In order to disable the compression the only thing
required is to comment out following line in interp_defs.h:
 #define COMPRESS_MODE
--
Ivan

On 2/2/07, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> wrote:
> I suppose there is no easy way to do that, but one can scan all places where
>
> #ifdef _EM64T_ appears and change appropriate places to something like
> #ifdef _COMPRESSED_MODE. Plus scan such places like gc_types.h in gc_cc,
> there is object header:
>     VT32 vt_raw;
>     unsigned info;
> You need to have VT64 vt_raw;  for 64 bit mode.
>
> p.s. In some of discussions I read that compressed mode (comparing to
> uncompressed one) improved performance on about 13% on em64t.
>
> On 2/2/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> > Yes, that's exactly my question. I couldn't find an easy way to turn
> > off this compressed-ptr optimization. It's a little bit surprising me.
> > :-)
> >
> > Thanks,
> > xiaofeng
> >
> > On 2/2/07, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> wrote:
> > > Did you check that it works on 64 bit mode with uncomressed references.
> > > I remember some time ago there were issues like hard coded compressed
> > > references used in JIT (or probably somewhere else) in 64bit mode.
> > >
> > > Best regards,
> > > Aleksey.
> > >
> > > On 2/2/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > >
> > > > Hi, current 64bit support uses compressed reference pointer by
> > > > default, i.e., a 64bit reference is stored as a 32bit value plus a
> > > > (global) base address. This can reduce the footprint of working set
> > > > and at the same time improve cache locality. But this has max heap
> > > > size limitation.
> > > >
> > > > I wonder why not use non-compressed pointer as by default, and the
> > > > compressed pointer is only an optimization that can be applied when
> > > > desirable. Comments?

Mime
View raw message