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] 64-bit support with compressed pointer
Date Fri, 02 Feb 2007 09:10:17 GMT
On 2/2/07, Henrik Stahl <hstahl@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 <hstahl@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 <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?
> > > > > > >
> > > > > > > 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.
>

Mime
View raw message