<div dir="ltr"><div><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hi,</span></div><div><i><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></i></div><i><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">One of the papers in that list is the 1997 techical report "The Space</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Overhead of Customization". One of the reasons that Java won over Self</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">was that its simple interpreter ran on 8MB machines that most of Sun's</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">customers had while Self needed 24MB workstations which were rare (but</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">would be very common just two years later). Part of that was due to</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">compiling a new version of native code for every different type of</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">receiver even if the different versions didn't really help.</span></i><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br>Note that Javascript people had the same issue and they built many work-around, such as fine-tuning transitions between hidden classes/map or sharing the code between hidden classes/map. <div><br><div>In addition, the Self VM featured a non optimizing and an optimizing JIT but no interpreter. The interpreter is the bit allowing to save memory there (code rarely used can be kept in the form of bytecode, which is usually ~5x more compact than n code, and unused compiled native code can be GC'ed). </div><div><br></div><div>So there's a lot to argue there. I don't think Java won because of technical issues but political ones, the Self VM could definitely have been patched to fix this issue.</div><div><br></div><div><i><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">My idea of allowing PICs to be optionally shared was that this would</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">allow customization to be limited in certain cases to save memory. It</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">would cause a loss of information about types seen at a call site, but</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">that doesn't always have a great impact on performance.</span></i><br><div class="gmail_extra"><br></div><div class="gmail_extra">We do that in the Cog for openPIC (Polymorphism of 6+ cases). In any case the optimizing JIT rarely optimizes more than 2 cases (though in some VM such as JSCore it can optimize up to 8 cases), so sharing openPICs makes sense.</div><div class="gmail_extra"><br></div><div class="gmail_extra">For closedPIC, i.e. the jump tables, I don't think they represent a lot of memory and indeed the type information is relevant, so, not sure about sharing those.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 25, 2018 at 1:18 AM, Jecel Assumpcao Jr. <span dir="ltr"><<a href="mailto:jecel@merlintec.com" target="_blank">jecel@merlintec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
While it is bad form to move a private discussion to (or back to) a<br>
public forum, some of these links might be interesting to people here<br>
and I have been unable to send emails to Tobias after my initial reply.<br>
An attempt on Wednesday and on Friday made <a href="http://mcrelay.correio.biz" rel="noreferrer" target="_blank">mcrelay.correio.biz</a> complain<br>
that <a href="http://mx00.emig.gmx.net" rel="noreferrer" target="_blank">mx00.emig.gmx.net</a>[ refused to talk to it and an attempt from my old<br>
1991 email account on Monday complained about the email address though<br>
it was ok as far as I can tell.<br>
<br>
Tobias wrote:<br>
> Jecel wrote:<br>
> > [new direction: emulate bytecodes and RISC-V]<br>
> <br>
> That'a an interesting take.<br>
> <br>
> I can only watch from afar, but its all interesting. (for example that guy <br>
> who does  RISC-V cpu in TTL chips: <a href="https://www.youtube.com/channel/UCBcljXmuXPok9kT_VGA3adg" rel="noreferrer" target="_blank">https://www.youtube.com/<wbr>channel/UCBcljXmuXPok9kT_<wbr>VGA3adg</a> )<br>
<br>
It is an interesting project. I was annoyed by his claim to have the<br>
first homebrew TTL 32 bit processor since in the late 1990s a group of<br>
students at the MIT processor design course implemented the Beta<br>
processor in TTLs instead of using FPGAs like all other groups (before<br>
or since). Sadly, all information about this has been eliminated from<br>
the web and can't even be found in <a href="http://archive.org" rel="noreferrer" target="_blank">archive.org</a>.<br>
<br>
I tried to get the local universities to teach RISC-V to their students<br>
instead of their own educational RISC processors but they are too<br>
emotionally attached to their designs.<br>
<br>
> Sounds reasonable. Let's have them know dynamic languages are also still there ;)<br>
> (I mean, you're very familiar with both Smalltalk and Self...)<br>
<br>
Mario Wolczko has been involved in Java since the late 1990s but was<br>
part of the Self group before that and had created the Mushroom<br>
Smalltalk computer before that.<br>
<br>
<a href="http://www.wolczko.com/" rel="noreferrer" target="_blank">http://www.wolczko.com/</a><br>
<br>
Boris Shingarov is currently involved with Java but has given a lot of<br>
talk about Smalltalk VMs and was involved in Squeak back in the OS/2<br>
days.<br>
<br>
<a href="http://shingarov.com/" rel="noreferrer" target="_blank">http://shingarov.com/</a><br>
<br>
With me, that was 3 out of 6 people at the meeting representing the<br>
Smalltalk viewpoint. We shall see if that will have any practical<br>
effect.<br>
<br>
> The TLB is somewhat maintained by the CPU to manage the translation of virtual addresses to physical ones.<br>
> <br>
> I can imagine something similar, like a branch, that upon return, updates a filed<br>
> in a PIC buffer, such that the next time the branch is only taken if a register (eg, class of the object) <br>
> is different or so.<br>
<br>
Ok, Mario actually mentioned that with today's advanced branch<br>
prediction hardware we might want to re-evaluate PICs. In this case you<br>
wouldn't be using the TLBs but the BTB (Branch Target Buffer) hardware.<br>
<br>
<a href="https://www.slideshare.net/lerruby/like-2014214" rel="noreferrer" target="_blank">https://www.slideshare.net/<wbr>lerruby/like-2014214</a><br>
<br>
Mario might have actually been thinking about Urs Hölzle's ECOOP 95<br>
paper, which was a slightly different subject.<br>
<br>
<a href="http://hoelzle.org/publications/ecoop95-dispatch.pdf" rel="noreferrer" target="_blank">http://hoelzle.org/<wbr>publications/ecoop95-dispatch.<wbr>pdf</a><br>
<br>
They were looking at the different kinds of software implementation of<br>
method dispatch (not only PICs) and the effects of processors executing<br>
more and more instructions per clock cycle. That might make a scheme<br>
that is bad for a simple RISC (due to many tests, for example) actually<br>
work well on an advanced out-of-order processor (due to the test being<br>
"free" since they execute in parallel with the main code). They didn't<br>
look at branch prediction hardware, but it certainly would have a huge<br>
impact. Several of the later papers focused on branch prediction:<br>
<br>
<a href="http://hoelzle.org/publications.html" rel="noreferrer" target="_blank">http://hoelzle.org/<wbr>publications.html</a><br>
<br>
> > For SiliconSqueak I actually had two different PIC instructions. They<br>
> > modified how the instruction cache works. Normally the instruction cache<br>
> > is accessed by hashing the 32 bit value of the PC except for the lowest<br>
> > bits which select a byte in the cache line, but after a PIC instruction<br>
> > the hash used a 64 bit value that combined the PC (all bits) and the<br>
> > pointer to the receiver's class. The resulting cache line was fetched<br>
> > and instructions executed in sequence even though the PC didn't change.<br>
> > Any branch or call instruction would restart normal execution at the new<br>
> > PC.<br>
> <br>
> Sounds neat!<br>
><br>
> > So a PIC entry takes up exactly one cache line. A PIC can have as many<br>
> > entries as needed and the instruction takes the same time to execute no<br>
> > matter how many entries there are (not taking into account cache<br>
> > misses).<br>
><br>
> Wow thats incredible.<br>
><br>
> > The second PIC instruction works exactly like the first but it supplies<br>
> > a different value to be used in place of the current PC. That allows<br>
> > different call sites to share PIC entries if needed, though that might<br>
> > be more complicated than it is worth.<br>
> <br>
> Maybe. What I like about PICs per send site is that you can essentially use them<br>
> as data source for dynamic feedback (what "types" where actually seen at this send site?)<br>
> and one probably would need some instructions to fetch those infos from the PIC.<br>
<br>
One of the papers in that list is the 1997 techical report "The Space<br>
Overhead of Customization". One of the reasons that Java won over Self<br>
was that its simple interpreter ran on 8MB machines that most of Sun's<br>
customers had while Self needed 24MB workstations which were rare (but<br>
would be very common just two years later). Part of that was due to<br>
compiling a new version of native code for every different type of<br>
receiver even if the different versions didn't really help.<br>
<br>
My idea of allowing PICs to be optionally shared was that this would<br>
allow customization to be limited in certain cases to save memory. It<br>
would cause a loss of information about types seen at a call site, but<br>
that doesn't always have a great impact on performance.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Jecel<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.com/</a></div></div></div></div></div></div>
</div></div></div></div>