On 2014-08-20 12:51, Jochen Theodorou wrote:
Am 19.08.2014 12:49, schrieb Raffaello Giulietti:
On 2014-08-18 20:48, Jochen Theodorou wrote:
Am 18.08.2014 12:01, schrieb Raffaello Giulietti:
[...]
...
hundreds of people. Unfortunately, not so for most Smalltalk VMs,
perhaps with the exception of Cog.
Yes... given the background it is no wonder. That's why I was wondering
about the constraints of the decision. Imho the JVM could be a better
host for all the reasons you pointed out above. But the step comes not
for free and extended memory costs will most likely be one of them...
given that the old VM did its job properly ;)
But given your application no doubt you will have to face two very big
problems if you want to make use of those advantages. One is the
translation of the Java memory model to smalltalk and your application
being aware of that. The other is integration with Java libraries. Java
has a different object model than smalltalk. And that is fine till you
have to interface with Java, that expects a Java object of a certain
class and wants to interact with it. This can turn into a huge amount of
plumbing code, that you cannot always hide. So you should be aware, that
you may end up translating more and more of your code to a JVM language
that uses the Java object model more or less.
To be clear, we have no real pressure to switch to an implementation of
Smalltalk/JVM in the short term, we are just exploring the possibility.
Apart from the lack of support for modern multi-everything hardware
architectures, we are quite happy with our Smalltalk platforms. But in
the long term general purpose Smalltalk implementations must face
reality and become multi-*, less they face extinction.
I agree. And if you see it as a long term investment, then things should
be fine. I mean even if you take on of the existing implementations it
may take a while to get it to behave like you want. I would contact some
of the authors and ask for their opinion. Well... at least one of them
is answering here already ;)
[...]
...
to be very worried about this point. Have you some figures, in
bytes/callsite perhaps?
I am not sure you can really give definitive numbers. I could talk now
about bugs and all, but fact is that this area in the JVM is not done
and still undergoes bigger changes.
My opinion is based on the experience that some users did complain about
the indy version needing more memory and my personal observations for
example about a simple Groovy program being able to run in about 40MB
memory, but needing quite a bit more with indy. Since I can observe the
memory drain with a small program already, and since I know that handles
are not that reusable yet...
But I think Mark Roos gave some figures ;)
bye Jochen
Thanks Jochen
I very much appreciate all opinions based on real-world experience.
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
