You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/02/02 06:49:40 UTC
[DRLVM] 64-bit support with compressed pointer
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?
Thanks,
xiaofeng
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 2/2/07, Henrik Stahl <hs...@bea.com> wrote:
>
> http://e-docs.bea.com/jrockit/jrdocs/refman/optionXX.html#wp1021022
>
> Though the docs are misleading, it is only enabled by default if -Xmx is
> 4 gb or less. I'll have this fixed.
Thanks!
-xiaofeng
> -- Henrik
>
> > -----Original Message-----
> > From: Xiao-Feng Li [mailto:xiaofeng.li@gmail.com]
> > Sent: Friday, February 02, 2007 9:55 AM
> > To: dev@harmony.apache.org
> > Subject: Re: [DRLVM] 64-bit support with compressed pointer
> >
> > Henrik, thanks for the link. I knew you guys got great number
> > with compressed refs.
> >
> > I assume the figure 2 in that page shows performance of same
> > configurations except for the processor bits. Probably the
> > real power of 64bit is with large heap size.
> >
> > Henrik, does JRockit turn on the compressed pointer by
> > default in 64bit platform? (if it's not confidential). Thanks,
> >
> > -xiaofeng
> >
> > On 2/2/07, Henrik Stahl <hs...@bea.com> wrote:
> > >
> > > We have this in 64-bit versions of BEA JRockit. See here for one
> > > performance proof point:
> > >
> > http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp
> > > 10
> > > 79760
> > >
> > > I guess the 13% number is close to the mark. It is app dependent,
> > > though.
> > >
> > > -- Henrik
> > >
> > > > -----Original Message-----
> > > > From: Aleksey Ignatenko [mailto:aleksey.ignatenko@gmail.com]
> > > > Sent: Friday, February 02, 2007 9:08 AM
> > > > To: dev@harmony.apache.org
> > > > Subject: Re: [DRLVM] 64-bit support with compressed pointer
> > > >
> > > > 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 <xi...@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
> > <al...@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 <xi...@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?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > xiaofeng
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > ______________________________________________________________________
> > > _
> > > Notice: This email message, together with any attachments, may
> > > contain information of BEA Systems, Inc., its
> > subsidiaries and
> > > affiliated entities, that may be confidential, proprietary,
> > > copyrighted and/or legally privileged, and is intended
> > solely for the
> > > use of the individual or entity named in this message. If
> > you are not
> > > the intended recipient, and have received this message in error,
> > > please immediately return this by email and then delete it.
> > >
> >
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
RE: [DRLVM] 64-bit support with compressed pointer
Posted by Henrik Stahl <hs...@bea.com>.
http://e-docs.bea.com/jrockit/jrdocs/refman/optionXX.html#wp1021022
Though the docs are misleading, it is only enabled by default if -Xmx is
4 gb or less. I'll have this fixed.
-- Henrik
> -----Original Message-----
> From: Xiao-Feng Li [mailto:xiaofeng.li@gmail.com]
> Sent: Friday, February 02, 2007 9:55 AM
> To: dev@harmony.apache.org
> Subject: Re: [DRLVM] 64-bit support with compressed pointer
>
> Henrik, thanks for the link. I knew you guys got great number
> with compressed refs.
>
> I assume the figure 2 in that page shows performance of same
> configurations except for the processor bits. Probably the
> real power of 64bit is with large heap size.
>
> Henrik, does JRockit turn on the compressed pointer by
> default in 64bit platform? (if it's not confidential). Thanks,
>
> -xiaofeng
>
> On 2/2/07, Henrik Stahl <hs...@bea.com> wrote:
> >
> > We have this in 64-bit versions of BEA JRockit. See here for one
> > performance proof point:
> >
> http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp
> > 10
> > 79760
> >
> > I guess the 13% number is close to the mark. It is app dependent,
> > though.
> >
> > -- Henrik
> >
> > > -----Original Message-----
> > > From: Aleksey Ignatenko [mailto:aleksey.ignatenko@gmail.com]
> > > Sent: Friday, February 02, 2007 9:08 AM
> > > To: dev@harmony.apache.org
> > > Subject: Re: [DRLVM] 64-bit support with compressed pointer
> > >
> > > 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 <xi...@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
> <al...@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 <xi...@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?
> > > > > >
> > > > > > Thanks,
> > > > > > xiaofeng
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ______________________________________________________________________
> > _
> > Notice: This email message, together with any attachments, may
> > contain information of BEA Systems, Inc., its
> subsidiaries and
> > affiliated entities, that may be confidential, proprietary,
> > copyrighted and/or legally privileged, and is intended
> solely for the
> > use of the individual or entity named in this message. If
> you are not
> > the intended recipient, and have received this message in error,
> > please immediately return this by email and then delete it.
> >
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Xiao-Feng Li <xi...@gmail.com>.
Henrik, thanks for the link. I knew you guys got great number with
compressed refs.
I assume the figure 2 in that page shows performance of same
configurations except for the processor bits. Probably the real power
of 64bit is with large heap size.
Henrik, does JRockit turn on the compressed pointer by default in
64bit platform? (if it's not confidential). Thanks,
-xiaofeng
On 2/2/07, Henrik Stahl <hs...@bea.com> wrote:
>
> We have this in 64-bit versions of BEA JRockit. See here for one
> performance proof point:
> http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp10
> 79760
>
> I guess the 13% number is close to the mark. It is app dependent,
> though.
>
> -- Henrik
>
> > -----Original Message-----
> > From: Aleksey Ignatenko [mailto:aleksey.ignatenko@gmail.com]
> > Sent: Friday, February 02, 2007 9:08 AM
> > To: dev@harmony.apache.org
> > Subject: Re: [DRLVM] 64-bit support with compressed pointer
> >
> > 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 <xi...@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 <al...@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 <xi...@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?
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > >
> > > >
> > >
> >
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
RE: [DRLVM] 64-bit support with compressed pointer
Posted by Henrik Stahl <hs...@bea.com>.
We have this in 64-bit versions of BEA JRockit. See here for one
performance proof point:
http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp10
79760
I guess the 13% number is close to the mark. It is app dependent,
though.
-- Henrik
> -----Original Message-----
> From: Aleksey Ignatenko [mailto:aleksey.ignatenko@gmail.com]
> Sent: Friday, February 02, 2007 9:08 AM
> To: dev@harmony.apache.org
> Subject: Re: [DRLVM] 64-bit support with compressed pointer
>
> 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 <xi...@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 <al...@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 <xi...@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?
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > >
> > >
> >
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Rana Dasgupta <rd...@gmail.com>.
We can clean some of this up when doing the Windows64 port. Then wait for
the jit to support the functionality, and switch the default.
On 2/2/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> Thanks, Aleksey. Well, it's not that easy. The object header layout
> change has interactions with some other modules like threading. And
> my original question is not about how to hack the code base for
> non-compressed pointer. I was just thinking it might be a good idea to
> make compressed pointer only a toggle-able optimization.
>
> Thanks,
> xiaofeng
>
> On 2/2/07, Aleksey Ignatenko <al...@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 <xi...@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 <al...@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 <xi...@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?
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thanks, Aleksey. Well, it's not that easy. The object header layout
change has interactions with some other modules like threading. And
my original question is not about how to hack the code base for
non-compressed pointer. I was just thinking it might be a good idea to
make compressed pointer only a toggle-able optimization.
Thanks,
xiaofeng
On 2/2/07, Aleksey Ignatenko <al...@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 <xi...@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 <al...@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 <xi...@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?
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > >
> > >
> >
>
>
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <al...@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 <xi...@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 <al...@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 <xi...@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?
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <xi...@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 <al...@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 <xi...@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?
> > >
> > > Thanks,
> > > xiaofeng
> > >
> >
> >
>
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <al...@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 <xi...@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?
> >
> > Thanks,
> > xiaofeng
> >
>
>
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <xi...@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?
>
> Thanks,
> xiaofeng
>
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 2/2/07, Mikhail Fursov <mi...@gmail.com> wrote:
> Xiao-Feng,
> Jitrino won't work with uncompressed references today, but uncompressed
> references support was taken into account in HLO and GC optimizations
> design. So I see no problems to support uncompressed references in JIT.
Thanks for the info. Great to know that.
Thanks,
xiaofeng
> On 2/2/07, Xiao-Feng Li <xi...@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?
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
> --
> Mikhail Fursov
>
>
Re: [DRLVM] 64-bit support with compressed pointer
Posted by Mikhail Fursov <mi...@gmail.com>.
Xiao-Feng,
Jitrino won't work with uncompressed references today, but uncompressed
references support was taken into account in HLO and GC optimizations
design. So I see no problems to support uncompressed references in JIT.
On 2/2/07, Xiao-Feng Li <xi...@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?
>
> Thanks,
> xiaofeng
>
--
Mikhail Fursov