Hello Thomas,
Thank you...we will be excited to get it delivered and move forward.
The purpose of the 64-bit project was about:
- Getting folks access to larger heaps so they don't run out of memory and crash after they cross the maximum addressable size within a 32-bit process
- Allowing for access to 64-bit shared libraries since some software distributors are no longer supplying 32-bit libraries
- Guarding against the accelerating trend of the removal of 32-bit operating system support
- Moving us away from a vm implementation using a very specialized code generator that we would need to maintain and extend for new platform support.
Some key constraints of the 64-bit project were to:
- Maintain the same vm specification (if for no other reason that this undertaking was enormous enough without having to take on other significant features)
- Maximum backwards compatibility (Our 32-bit vm should still be able to run something as old as a visualage 3.0 image)
The way this was accomplished was:
- Implementing brand new 32-bit and 64-bit virtual machines that conform to the original vm specification
- New 64-bit Swapper subsystem that could read/write 32-bit object formats (in addition to 64-bit formats)
- Think of all the serialized objects that exist in an ENVY .dat file as configuration settings or whatever. If this were not the case, a 32-bit image would simply die if it attempted to connect to the same repository that a 64-bit image had written objects to that the 32-bit image tried to read)
- New 64-bit image loader that could detect and translate 32-bit images and ICs on-the-fly into it's equivalent 64-bit counterpart
- Major image modifications
- Chasing down all the magic numbers all over the image that somehow assume 32-bit (i.e. 12 -- the 32-bit object header size, 4 -- was often the assumed size of a pointer....and so)
- Modification to all existing platform functions that were written for 32-bit. (i.e. #uint32 to represent a pointer address argument in the windows api)
- Auto size/alignment calculator is OSStructure to move away from "access an OSObject by offset" and general updates to the whole OSObject framework
- 64-bit packaging capability which is still in progress.
- There is a lot more over the years we were forced to address but this is just to name a few issues.
Mutli-core support
"Mutli-core support" has a lot of ambiguity in that name, so I'm not exactly sure what you mean, but I can kind of guess.
You could mean..."Does the vm, itself, in isolation of what's happening in Smalltalk execution, use more than 1 core to do anything?"
- The answer is no, not yet, but it will. This will be the reworked garbage collector where all of the GC algorithms will use multiple native threads. So in that sense, it will become a multi-core vm
You could mean..."Can you use multiple native threads as any part of smalltalk programming execution?"
- So, certainly we have asynchronous callouts, which allows for external calls to be tied to a native thread...so in this sense, we offer support for multi-core already, and that is vm assisted.
- We don't, and probably never will, have support for something like java native threads, where you can have multiple Smalltalk processes executing code and modifying the heap concurrently.
- The smalltalk libraries are not setup for this...things like collections will break
- Adds a lot of complexity to the memory manager when you have to deal with multiple allocators against a shared heap. Basically we would have to redesign it.
- Needs new library support to deal with concurrency at the level we would want to use it in smalltalk....a thread is too low-level a concept.
- I personally would fear native thread concurrency-related support cases:)
You could mean..."Can you do anything that involves using multiple execution units in a single logical program?"
- As I mentioned, it's not what this project was about...but ultimately...yes
- There are possibilities like Dart-isolates, or basically a mechanism with separate heaps and an efficient controlled communication mechanism
- There are additions (and really, massive simplification) that we could do to expose and enhance some of the existing SST capability
So there is lots of potential for multi-core, regardless of what specifically we mean, but I would pretty much not count on java-style native threads...and mostly on purpose.
Thanks for the feedback.
-- Seth
On Friday, June 16, 2017 at 12:12:16 PM UTC-4, Thomas Stalzer wrote:
Hello @InstantiationsSmalltalkTeam
Good job - it is good to know that VA/ST is moving forward.
I kind of was hoping that the new VM supports more than one core on a multi core system. However (at least under Windows), I do not get more than 25% usage on a 4-core system...
--Thomas
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[hidden email].
To post to this group, send email to
[hidden email].
Visit this group at
https://groups.google.com/group/va-smalltalk.
For more options, visit
https://groups.google.com/d/optout.
Locked
