Some nice comments from Rémi
So if one call is not inlined in
the middle of the body of the loop, then the VM will
not remove your MutableInteger.
This could be what is causing the difference in time. I have seen some
mails that indicate indy
GWT depth ( methodHandle stacks ) impacts the inlining budget. So a
change in the size of my
polymorphic cache could have a big impact. I would think that a GWT test
is cheap to inline though.
You are correct that I can replace the indy calls on Mutable integer with
my own inline byte codes
which I think it a good idea.
and
??, yes your debugger has to support it, but if you
want a typed smalltalk you will need that anyway.
My intent for 'typed' Smalltalk code is to replace the 1000 lines or so of
java code I have to have
to support primitive methods. If I could generate the jvm byte codes from
a Smalltalk syntax I would
cut the need to write java just to get the performance improvements
available from having static
type information.
My debugger issue is with unboxed primitives which I would like to hide as
much as possible until
Fixnums appear
thanks
mark_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
