How to tell if an image is 64bit?

Inside VisualWorks, I cannot find information on whether the image is 64bit or not.
How can I do that?

Thanks,
Aik-Siong Koh

Try evaluating ObjectMemory is64Bit.

On 4/16/13 10:18 AM, askoh wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Is it possible to run in mixed mode?

We're dependent on some 3rd party librararies that are 32-bit.

It would be nice to be able to run the image and build executables in
64-bit, but communicate with the libraries in 32-bit?

Thank you,

Gary P





----- Original Message -----
From: "Andres Valloud" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, April 16, 2013 12:21 PM
Subject: Re: [vwnc] How to tell if an image is 64bit?


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Nope.  So why would you want to run a 64 bit image with 32 bit libraries?

On 4/18/13 6:59 PM, Gary Peterson wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks for the clarification Andres,

Assumed that the 64-bit image would just be the better mode (generally), but
could be wrong.

Migrating to 7.9.1 we're bumping into new memory/primitive issues -- usually
loading/publishing. Issues in both a 32-bit and 64-bit image, but maybe a
bit less for the 64-bit case -- thus the question.

Looking at other resolution avenues -- reogranizging code (partitioning some
much larger bundles) has helped.

Cranking up the memory settings has helped per the group's sugs.

We did try toggling load policies e.g. shadow loader / atomic, etc. per sugs
from the group, but for our case that made things worse.

Thank you,

Gary P





----- Original Message -----
From: "Andres Valloud" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, April 18, 2013 9:34 PM
Subject: Re: [vwnc] How to tell if an image is 64bit?


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Gary, please keep in touch with support re: memory issues loading and
unloading packages.  I'm not immediately connected to those problems,
however if my memory serves me right some of us have been dealing with
those already.

On 4/18/13 8:03 PM, Gary Peterson wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thank you and will do Andres,

Yes -- have had communications/tickets with support and will definately
continue to tap into that source.

gp






----- Original Message -----
From: "Andres Valloud" <[hidden email]>
To: "Gary Peterson" <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, April 18, 2013 10:07 PM
Subject: Re: [vwnc] How to tell if an image is 64bit?


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dear Gary,
    some minor questions just to understand your case.

> Migrating to 7.9.1 we're bumping into new memory/primitive issues --
> usually loading/publishing.

Migrating from which version?

>
> We did try toggling load policies e.g. shadow loader / atomic, etc.
> per sugs from the group, but for our case that made things worse.

(Just checking) you mean found that when you switched off using any
atomic load, loading got slower and/or needed yet more memory?

             Yours faithfully
                   Niall Ross


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thank you Niall,

> Migrating from which version?

7.6 (I understand this is a pretty big hop -- to 7.9)

> (Just checking) you mean found that when you switched off using any atomic
> load, loading got slower and/or needed yet more memory?

It's been a while since trying this -- but basically we gave most/all of the
combinations a try (on/off atomic loader and/or the analysis loader). For
these attempts, we hit other (non memory related) issues/errors. Because
this route presented new problems, we did not spend too much time
investigating or documenting these. We could always go back to this path and
spend more time on it if we thought it would help. But in regard to your
question, the issues did not appear to be mem related.

Our code is probably unique relative to it's volume (been around quite a
while with large teams involved at times).Increasing memory upper bounds has
helped some. Partitioning some of our larger bundles (as simplistic as this
might be) seems to have helped us the most.

Also it seems we had some better luck in a 64-bit image; however we need our
migrated result to be 32-bit. Probably makes sense to migrate in a 64-bit
image e.g. working thru issues and reorganizing. Then see how the final
migrated result loads into a 32-bit image...

Thank you,

Gary P









----- Original Message -----
From: "Niall Ross" <[hidden email]>
To: "Gary Peterson" <[hidden email]>
Cc: "Andres Valloud" <[hidden email]>; <[hidden email]>
Sent: Friday, April 19, 2013 2:38 PM
Subject: Re: [vwnc] How to tell if an image is 64bit?


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Gary,

I suppose this is as good a place to say it as any: The atomic and analysis loaders aren't for everyone, which is why there is still an non atomic loader that is invoked when the atomic loader(s) are turned off.

The goals of the atomic loader(s) are to work around the problems that can arise in the non atomic loader when classes, namespaces and shared variables are installed in an not carefully defined order. Some examples of this are shared variables that rely on other shared variables to be initialized, class initializers that rely on sibling classes to be executed and so on.

But even if you have carefully defined #prerequisitesForLoading methods, crafted each initializer to be non-dependent or late bound, you could still have problems.

For instance if you had 100 packages in a bundle with loads of code, the analysis loader will attempt to load into shadow objects each  definition object. That could cause a memory to become an issue.

Each of the loaders have their reason for being, and while most will simply be able to use the default analysis loader, others will need one of the others.

The high level differences are:

        * Analysis Loader: Attempts to load everything in as few "From Definition To Live" steps as possible. Can deal with definitions that are out of order, with regard to their position in the load order of their owning package within a bundle.
        * Atomic Loader: Like the analysis loader, attempts to load everything in as few "From Definition To Live" steps as possible. Installs objects in package load order.
        * Direct Non-Atomic Loader: Loads each definition object at a time in package load order.

> It's been a while since trying this -- but basically we gave most/all of the combinations a try (on/off atomic loader and/or the analysis loader). For these attempts, we hit other (non memory related) issues/errors. Because this route presented new problems, we did not spend too much time investigating or documenting these. We could always go back to this path and spend more time on it if we thought it would help. But in regard to your question, the issues did not appear to be mem related.
>
> Our code is probably unique relative to it's volume (been around quite a while with large teams involved at times).Increasing memory upper bounds has helped some. Partitioning some of our larger bundles (as simplistic as this might be) seems to have helped us the most.


                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thank you for the summary Samuel; we'll reference this as we go....


----- Original Message -----
From: "Samuel S. Shuster" <[hidden email]>
To: "Gary Peterson" <[hidden email]>
Cc: "Niall Ross" <[hidden email]>; <[hidden email]>
Sent: Tuesday, April 23, 2013 11:49 AM
Subject: Re: [vwnc] How to tell if an image is 64bit?


Gary,

I suppose this is as good a place to say it as any: The atomic and analysis
loaders aren't for everyone, which is why there is still an non atomic
loader that is invoked when the atomic loader(s) are turned off.

The goals of the atomic loader(s) are to work around the problems that can
arise in the non atomic loader when classes, namespaces and shared variables
are installed in an not carefully defined order. Some examples of this are
shared variables that rely on other shared variables to be initialized,
class initializers that rely on sibling classes to be executed and so on.

But even if you have carefully defined #prerequisitesForLoading methods,
crafted each initializer to be non-dependent or late bound, you could still
have problems.

For instance if you had 100 packages in a bundle with loads of code, the
analysis loader will attempt to load into shadow objects each  definition
object. That could cause a memory to become an issue.

Each of the loaders have their reason for being, and while most will simply
be able to use the default analysis loader, others will need one of the
others.

The high level differences are:

* Analysis Loader: Attempts to load everything in as few "From Definition To
Live" steps as possible. Can deal with definitions that are out of order,
with regard to their position in the load order of their owning package
within a bundle.
* Atomic Loader: Like the analysis loader, attempts to load everything in as
few "From Definition To Live" steps as possible. Installs objects in package
load order.
* Direct Non-Atomic Loader: Loads each definition object at a time in
package load order.


                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc