[Vm-dev] PICs (was: RISC-V J Extension)

[Jecel Assumpcao Jr.]

Clément Bera wrote on Wed, 25 Jul 2018 08:12:53 +0200
> > One of the papers in that list is the 1997 techical report "The Space
> > Overhead of Customization". One of the reasons that Java won over Self
> > was that its simple interpreter ran on 8MB machines that most of Sun's
> > customers had while Self needed 24MB workstations which were rare (but
> > would be very common just two years later). Part of that was due to
> > compiling a new version of native code for every different type of
> > receiver even if the different versions didn't really help.
> 
> 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.

Since changing an object is a more lightweight operation in Javascript
than in Self it makes a higher performance implementation even more
complicated. But the stuff that helps Javascript can also be used to
improve Self.

> 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). 

That is one of the thing David Ungar changed from Self 4.0 to 4.1 long
after the project was officially over. That was only released in 2002 or
so. I am not sure if the current Self includes an interpreter, but its
bytecodes are designed to allow one.

> 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.

Exactly! For those who are not aware of the history, the Sun research
group developed an interesting operating system called SpringOS based on
Java. When they started publishing papers, Sun's customers started to
get nervous because they had just suffered through the transition from
SunOS (BSD) to Solaris (Unix System V) and told Sun they would switch to
some competitor instead of dealing with SpringOS. So Sun cancelled the
research project and made it very clear that they were "Solaris
forever". This made marketing look at their language situation, so they
decided to be a "Java only forever" and kill everything else.

About the memory excuse, I pointed out Java only had a trivial
interpreter running simple demos. Their only large application was the
HotJava web browser, and David Ungar implemented one with an equivalent
functionality in Self in a single afternoon (and the browser only added
a few KB to the size of the image file). I claimed that by the time Java
did half as much as Self it would be twice as large. I was wrong - it
was many times larger.

> > My idea of allowing PICs to be optionally shared was that this would
> > allow customization to be limited in certain cases to save memory. It
> > would cause a loss of information about types seen at a call site, but
> > that doesn't always have a great impact on performance.
> 
> 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.
> 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.

I don't think sharing is a good idea, but I didn't want to make it
impossible.

Tobias Pape wrote:
> That makes a lot of sense. Maybe there's a way to have both variants?

Yes, I had two different instructions. But like I said above, I didn't
really expect to use the second variation (shared PICs) but want to have
it in case somebody needed it someday. I do know that is not how you are
supposed to design a processor :-) Or even agile software, where the
motto is "you are not going to need it".

> > [TTL RISC-V is neat, but not first]
> Yea but as far as I can see that person is fine with being corrected, so
> maybe someone should tell him? :)

I don't like to claim stuff without being able to show proof. And it
isn't really important. But saying something was first in computer
history is pretty complicated.

-- Jecel