[Vm-dev] Large 64-bit object memory (was: VM Maker: VMMaker.oscog-eem.281.mcz)

[Igor Stasenko]

nice! :)

On 15 April 2013 01:15, David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Sat, Apr 06, 2013 at 09:30:11PM -0400, David T. Lewis wrote:
>>
>> On Sat, Apr 06, 2013 at 05:15:43PM -0700, Eliot Miranda wrote:
>> >
>> > On Thu, Apr 4, 2013 at 5:19 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>> >
>> > >
>> > > On Thu, Apr 04, 2013 at 01:25:10PM -0700, Eliot Miranda wrote:
>> > > >
>> > > > On Thu, Apr 4, 2013 at 3:17 AM, Nicolas Cellier <
>> > > > nicolas.cellier.aka.nice at gmail.com> wrote:
>> > > >
>> > > > >
>> > > > > Yes, I always wanted to ask what oops signed-ness was good for?
>> > > > > IMO, they could simply be declared usqInt.
>> > > > >
>> > > >
>> > > > +10 raisedTo: SmallInteger maxVal.  But the milk is already spilt :)
>> > > >
>> > > > I'm glad you said that.  I'm reminded of House of Cards.  "You might
>> > > think
>> > > > so but I couldn't possibly comment." ;)
>> > > >
>> > > > It might be worth-while trying to make this change and fixing the very
>> > > few
>> > > > places where signedness is important (the SmalInteger arithmetic
>> > > > primitives).
>> > > >
>> > >
>> > > IMO an object pointer should be declared sqOop to clearly distinguish
>> > > it from some something that is intended to be used as an integer.
>> >
>> >
>> > OK, but is sqOop a void pointer or what?  void pointers are ok except that
>> > they have to be cast all the time.  char * is poor; too easily confused
>> > with other pointers.  sqObj * (where sqObj is some opaque struct) is good.
>> >  Integral types are easy to deal with.  But signedness is the major thing
>> > to avoid.  SO either unsigned or pointer.  But which?
>> >
>>
>> You are missing my point. If someone is going to go to the trouble of
>> properly declaring object pointers, then they may as well use an intention
>> revealing type declaration.
>>
>> In principle there is no reason that an object pointer should not refer to
>> the primary key in a relational database table (to pick an intentionally
>> rediculous example). But an object pointer is an object pointer, it is
>> not an integer and it is not a C pointer.
>>
>> In practice, the current use of sqInt to represent object pointers is
>> confusing, but is not a big problem. After all, object memories of over
>> 7 GB work fine with the 64-bit object format (limited by physical memory
>> on my PC as far as I can tell). Although I note with dismay that there
>> seems to be yet another regression here, so I'll need to hunt that down
>> once more :-/
>
> OK, no regression after all, just a few type definitions required in the
> unix platforms sources (attached, along with SystemReporter stats that show
> the memory usage).
>
> With an up-to-date Squeak trunk image traced to 64-bit object format
> (from http://build.squeak.org/job/Squeak%2064-bit%20image/), and running
> on a Linux PC with 8GB memory, I can allocate large strings until the
> system bogs down with swapping at an image size of about 7GB. I can also
> successfully allocate e.g. a 6GB String or ByteArray, although indexing
> into the array fails due to issues unrelated to object pointer addressing.
>
> Dave
>
>



-- 
Best regards,
Igor Stasenko.