Although there are Java bytecode processors (even one available on
Github, https://github.com/amal029/jop) they have had very limited
success.

Why? A lot of commercial code runs on JVM now (I've heard quipped
that Java is the new COBOL), and I would expect significant
performance increase from a native implementation as opposed to
an interpreter or a JIT compiler. Or have JIT compilers become
so good that it no longer matters, and the effort of introducing
a new architecture would be too large (again)?

On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
> Although there are Java bytecode processors (even one available on
> Github, https://github.com/amal029/jop) they have had very limited
> success.
>
> Why?
<
A Bytecode interpreter, even in HW will have a serious performance
issue when compared to a cross compiling native instruction set.
Probably around 2×-3× penalty.
<
> A lot of commercial code runs on JVM now (I've heard quipped
> that Java is the new COBOL), and I would expect significant
> performance increase from a native implementation as opposed to
> an interpreter or a JIT compiler. Or have JIT compilers become
> so good that it no longer matters, and the effort of introducing
> a new architecture would be too large (again)?
<
JIT compilers compile to native ISA and perform reasonable
optimizations; a bytecode interpreter is always at the mercy
of the interpreter, even when done in HW. Can you get a bytecode
interpreter to run 3-4 bytes per cycle ? continuously ?

On 9/5/2021 6:05 PM, MitchAlsup wrote:
> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>> Although there are Java bytecode processors (even one available on
>> Github, https://github.com/amal029/jop) they have had very limited
>> success.
>>
>> Why?
> <
> A Bytecode interpreter, even in HW will have a serious performance
> issue when compared to a cross compiling native instruction set.
> Probably around 2×-3× penalty.

I think there is a reason why stack-oriented ISAs are no longer a thing.

Either the stack would need to map to registers, or be treated as a
special sort of special-purpose cache. The stack is also likely to
become a serious bottleneck if one can't schedule multiple
stack-operations per clock-cycle, and one would need to either operate
at a somewhat higher clock-speed or execute a large number of
instructions per cycle to be performance competitive with a 3R ISA.

> <
>> A lot of commercial code runs on JVM now (I've heard quipped
>> that Java is the new COBOL), and I would expect significant
>> performance increase from a native implementation as opposed to
>> an interpreter or a JIT compiler. Or have JIT compilers become
>> so good that it no longer matters, and the effort of introducing
>> a new architecture would be too large (again)?
> <
> JIT compilers compile to native ISA and perform reasonable
> optimizations; a bytecode interpreter is always at the mercy
> of the interpreter, even when done in HW. Can you get a bytecode
> interpreter to run 3-4 bytes per cycle ? continuously ?
>

Yeah. When translating from a stack IR to a 3AC IR, the number of
operations tends to actually shrink somewhat.

Say:
iload 7
iconst 13
iadd
istore 6

Might, in a 3R ISA, turn into a single instruction, say:
ADD R9, 13, R11

....

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>> Although there are Java bytecode processors (even one available on
>> Github, https://github.com/amal029/jop) they have had very limited
>> success.
>>
>> Why?
><
> A Bytecode interpreter, even in HW will have a serious performance
> issue when compared to a cross compiling native instruction set.
> Probably around 2×-3× penalty.

Of course, the latency of the first-time compilation is somewhat
large :-)

It is interesting to read the claims about picojava, which are
(unfortunately) not substantiated anywhere where I can get
to without a paywall.

The claims are about the same level of efficiency for C/C++ code,
and about a factor of 20 vs. an interpreter.

Of course, they were also looking at the embedded market, where
JIT compilation is definitely out.

><
>> A lot of commercial code runs on JVM now (I've heard quipped
>> that Java is the new COBOL), and I would expect significant
>> performance increase from a native implementation as opposed to
>> an interpreter or a JIT compiler. Or have JIT compilers become
>> so good that it no longer matters, and the effort of introducing
>> a new architecture would be too large (again)?
><
> JIT compilers compile to native ISA and perform reasonable
> optimizations; a bytecode interpreter is always at the mercy
> of the interpreter, even when done in HW. Can you get a bytecode
> interpreter to run 3-4 bytes per cycle ? continuously ?

Me, certainly not. Anybody else... I don't know :-)

MitchAlsup wrote:
> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>> Although there are Java bytecode processors (even one available on
>> Github, https://github.com/amal029/jop) they have had very limited
>> success.
>>
>> Why?
> <
> A Bytecode interpreter, even in HW will have a serious performance
> issue when compared to a cross compiling native instruction set.
> Probably around 2×-3× penalty.
> <
>> A lot of commercial code runs on JVM now (I've heard quipped
>> that Java is the new COBOL), and I would expect significant
>> performance increase from a native implementation as opposed to
>> an interpreter or a JIT compiler. Or have JIT compilers become
>> so good that it no longer matters, and the effort of introducing
>> a new architecture would be too large (again)?
> <
> JIT compilers compile to native ISA and perform reasonable
> optimizations; a bytecode interpreter is always at the mercy
> of the interpreter, even when done in HW. Can you get a bytecode
> interpreter to run 3-4 bytes per cycle ? continuously ?
>
I have to agree 100% with Mitch here:

A Java hw machine has been suggested many times, and it has always been
a (bad) solution in search of a problem.

In my current daytime work (for https://cognite.com/, a cloud-agnostic
industrial IT provider) we use several JVM-based languages, including
both Java and Kotlin as well as Scala, and the JIT compilers are just
Good Enough, and if/when they are not, then clang have native compilers
for both Java and Kotlin.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Thomas Koenig <tkoenig@netcologne.de> writes:
>Although there are Java bytecode processors (even one available on
>Github, https://github.com/amal029/jop) they have had very limited
>success.
>
>Why?

The JavaVM has not been designed for hardware implementation, and as a
result AFAIK all "hardware implementations" were partial, and fell
back to software assist for some instructions.

Also, what would the advantage of such a hardware implementation be?

A lot of commercial code runs on JVM now (I've heard quipped
>that Java is the new COBOL), and I would expect significant
>performance increase from a native implementation as opposed to
>an interpreter or a JIT compiler. Or have JIT compilers become
>so good that it no longer matters, and the effort of introducing
>a new architecture would be too large (again)?

JIT compilers certainly have become pretty good a long time ago, and
do things that "hardware implementations" at the time would not do:
E.g., escape analysis to optimize "new" into stack allocation;
determine the target of invokevirtual, inline it and use the resulting
knowledge for optimization.

In the meantime hardware designers do or at least think of things that
used to be available only in compilers, such as move elimination
(introduced in Intel CPUs with Sandy Bridge), or VVM. So maybe these
days the hardware would look better than it looked in earlier times;
IIRC both SPARC and ARM did their "hardware implementations" at a time
when they were only doing in-order CPUs. However, I don't think that
hardware can make escape analysis unnecessary, so hardware would have
to overtake JIT compilers in some places in order to make up for the
places where it is deficient.

Or one could think about whether you can get away from directly
executing JavaVM code without JIT, and combine both approaches.
Things that come to my mind would be to use the hardware
implementation for running the cold code (or code that has not yet
been found to be hot), with hardware supporting the profiling to find
hot spots, and then the compiler optimizes the hot spots. Will the
hardware implementation provide an advantage over other instruction
sets for the optimized code?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> writes:
>On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>> Although there are Java bytecode processors (even one available on=20
>> Github, https://github.com/amal029/jop) they have had very limited=20
>> success.=20
>>=20
>> Why?=20
><
>A Bytecode interpreter, even in HW will have a serious performance
>issue when compared to a cross compiling native instruction set.
>Probably around 2=C3=97-3=C3=97 penalty.

Why do you think so?

>JIT compilers compile to native ISA and perform reasonable
>optimizations; a bytecode interpreter is always at the mercy
>of the interpreter, even when done in HW.

When done in hardware, it's not an interpreter, it's an instruction
set.

>Can you get a bytecode
>interpreter to run 3-4 bytes per cycle ? continuously ?

Can you decode x register machine instructions per cycle?
Continuously?

I see no unsurmountable hurdles to create a JavaVM front end for an
appropriate OoO machine that produces a similar utilization of the FUs
of the OoO machine. Note that there is no aliasing problem wrt the
locals slots on the JavaVM.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 05/09/2021 23:05, Thomas Koenig wrote:
> Although there are Java bytecode processors (even one available on
> Github, https://github.com/amal029/jop) they have had very limited
> success.
>
> Why? A lot of commercial code runs on JVM now (I've heard quipped
> that Java is the new COBOL), and I would expect significant
> performance increase from a native implementation as opposed to
> an interpreter or a JIT compiler. Or have JIT compilers become
> so good that it no longer matters, and the effort of introducing
> a new architecture would be too large (again)?
>

Does JIT represent a threat to computer security?

We rely on memory divisions to be read-only, read / write or
execute-only but JIT (Just In Time) compilation means using
source code as data, returning compiled code as data, and then
executing that compiled code from a memory division that must
be executable read / write.

This seems like a recipe for viruses!

gareth evans <headstone255@yahoo.com> writes:
>This seems like a recipe for viruses!

This sentence *is* a recipe for security theatre.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

> I see no unsurmountable hurdles to create a JavaVM front end for an
> appropriate OoO machine that produces a similar utilization of the FUs
> of the OoO machine. Note that there is no aliasing problem wrt the
> locals slots on the JavaVM.

Whether a JVM CPU is possible (and even efficient) is probably
a hypothetical question at this point. The main question is: where's
the market for it?

Reminds me of the Lisp machines,

Stefan

On 9/6/2021 8:44 AM, Stefan Monnier wrote:
>> I see no unsurmountable hurdles to create a JavaVM front end for an
>> appropriate OoO machine that produces a similar utilization of the FUs
>> of the OoO machine. Note that there is no aliasing problem wrt the
>> locals slots on the JavaVM.
>
> Whether a JVM CPU is possible (and even efficient) is probably
> a hypothetical question at this point. The main question is: where's
> the market for it?
>

ARM had Jazelle DBX previously, which did a basic set of JVM
instructions in hardware and would jump back to ARM code for anything it
couldn't handle.

A little later on, Jazelle was all but dead, killed off mostly in favor
of JIT compiling the JVM bytecode to ARM / Thumb instructions.

I suspect there are reasons it happened this way.

I mostly suspect that a possible reason is that if one executes most
basic JVM instructions at, say, one instruction per cycle; then normal
ARM code (also running at one instruction per cycle) would effectively
run circles around it.

Though, FWIW, there could be more incentive for an ISA to have partial
emulation for x86 instructions, say:
0/1 prefix bytes;
1/2 opcode bytes;
optional Mod/RM;
optional immed.

And then trap back to an emulator for anything which does not fit this
pattern. Say, for example, it only supports a Load/Store subset of x86,
no SIB byte, ...
MOV EAX, [ECX+0x7C] //native execution
ADD ECX, EAX //native execution
...
MOV EDX, [ECX+4*EAX+0x4000] //trap
ADD EAX, [EDX] //trap (not Load/Store)

....

Does leave open how much of x86 could be run with such restrictions.
Would likely need hardware support for emulating x86 EFLAGS behavior and
similar though, ...

> Reminds me of the Lisp machines,
>
>
> Stefan
>

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I see no unsurmountable hurdles to create a JavaVM front end for an
>> appropriate OoO machine that produces a similar utilization of the FUs
>> of the OoO machine. Note that there is no aliasing problem wrt the
>> locals slots on the JavaVM.
>
>Whether a JVM CPU is possible (and even efficient) is probably
>a hypothetical question at this point. The main question is: where's
>the market for it?

A lot of code is written in Java, so if a hardware JavaVM
implementation provides a significant advantage for that, there should
be a big market (possibly as additional decoder for otherwise
general-purpose hardware, or by adding instructions for missing C
operations to the JavaVM instruction set).

>Reminds me of the Lisp machines,

I think in this case you need to analyse the actual factors involved.

Lisp Machines came out of the 1970s when bit-slice technology made it
relatively cheap (in manpower) to design a CPU, and they provided an
advantage in e.g., tag-handling and cdr-handling, and were faster at
that than other CPUs done in similar technology. But the RISC
revolution killed both the other CPUs done in similar technology and
Lisp machines (and one of the AI winter's helped the demise along).
RISCs with small extensions that can be useful for implementing Lisp
were developed: SOAR on the academic level, and some of that went into
SPARC on the commercial level.

The JavaVM hardware efforts (picoJava, Jazelle DBX) were done in the
late 1990s when Java JIT compilers did not play a role (at least when
the projects were started). Jazelle DBX was a front end for an ARM9
(not ARM v9), a single-issue in-order CPU; not much is known about
picoJava (it never became a product), but given the other designs that
Sun did at the time, I don't expect it to be OoO, and probably not
superscalar, either (with in-order, superscalar stack machines are
hard). This was in a world where OoO CPUs were winning and in
particular Intel and AMD were into the GHz race and crushed basically
all other architectures in the process, presumably not because of the
superior architecture, but because of superior microarchitecture,
superior circuit design, and maybe also superior process technology.

These days, we do not see much generational speedup, so architectural
differences can play a bigger role now. You can afford to spend a
year more on designing a CPU if it gives you 20% speedup (in the 1990s
this would have been the recipe for defeat), although it's still
better to releas the slow version now and the improved version in a
year. OTOH, designing a competetive microarchitecture is a pretty big
task these days, it's not like in the Lisp Machine days. So if a
hardware JavaVM has an advantage in some market over a conventional
architecture and a JIT, the chances are probably much better now than
they were in 1985-2005. The question is if the "if" is satisfied.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Monday, September 6, 2021 at 2:51:02 AM UTC-5, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
> >> Although there are Java bytecode processors (even one available on=20
> >> Github, https://github.com/amal029/jop) they have had very limited=20
> >> success.=20
> >>=20
> >> Why?=20
> ><
> >A Bytecode interpreter, even in HW will have a serious performance
> >issue when compared to a cross compiling native instruction set.
> >Probably around 2=C3=97-3=C3=97 penalty.
>
> Why do you think so?
<
Intuition, plus the bytecode is for a stack machine.
<
> >JIT compilers compile to native ISA and perform reasonable
> >optimizations; a bytecode interpreter is always at the mercy
> >of the interpreter, even when done in HW.
> When done in hardware, it's not an interpreter, it's an instruction
> set.
> >Can you get a bytecode
> >interpreter to run 3-4 bytes per cycle ? continuously ?
<
> Can you decode x register machine instructions per cycle?
> Continuously?
<
Yes.
>
> I see no unsurmountable hurdles to create a JavaVM front end for an
> appropriate OoO machine that produces a similar utilization of the FUs
> of the OoO machine. Note that there is no aliasing problem wrt the
> locals slots on the JavaVM.
<
The stack nature of the bytecode is the most significant imposition.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>>> Although there are Java bytecode processors (even one available on
>>> Github, https://github.com/amal029/jop) they have had very limited
>>> success.
>>>
>>> Why?
>> <
>> A Bytecode interpreter, even in HW will have a serious performance
>> issue when compared to a cross compiling native instruction set.
>> Probably around 2×-3× penalty.
>
> Of course, the latency of the first-time compilation is somewhat
> large :-)
>
> It is interesting to read the claims about picojava, which are
> (unfortunately) not substantiated anywhere where I can get
> to without a paywall.

1997 paper by Sun engineers on picoJava uArch and benchmarks says
it was 15-20 times faster than a 486/33 running interpreter,
and about 7-10 times faster than JIT.

picoJava-I: The Java Virtual Machine in Hardware, 1997
https://tsunami.zaibatsutel.net/liberez/picojava.pdf

On Monday, September 6, 2021 at 5:34:59 AM UTC-5, gareth evans wrote:
> On 05/09/2021 23:05, Thomas Koenig wrote:
> > Although there are Java bytecode processors (even one available on
> > Github, https://github.com/amal029/jop) they have had very limited
> > success.
> >
> > Why? A lot of commercial code runs on JVM now (I've heard quipped
> > that Java is the new COBOL), and I would expect significant
> > performance increase from a native implementation as opposed to
> > an interpreter or a JIT compiler. Or have JIT compilers become
> > so good that it no longer matters, and the effort of introducing
> > a new architecture would be too large (again)?
> >
> Does JIT represent a threat to computer security?
<
Absofriggenlutely !
>
> We rely on memory divisions to be read-only, read / write or
> execute-only but JIT (Just In Time) compilation means using
> source code as data, returning compiled code as data, and then
> executing that compiled code from a memory division that must
> be executable read / write.
<
Which is why the JIT should have write only access to the area
it keeps compiled code, and the consumer of that code have
execute only access.
>
> This seems like a recipe for viruses!
<
Where do you think viruses come from ?? eXcel !?!

On 06/09/2021 17:16, MitchAlsup wrote:
> Which is why the JIT should have write only access to the area
> it keeps compiled code, and the consumer of that code have
> execute only access.

Suggesting that the running application and the JIT compiler
run as coroutines

EricP wrote:
> Thomas Koenig wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>>>> Although there are Java bytecode processors (even one available on
>>>> Github, https://github.com/amal029/jop) they have had very limited
>>>> success.
>>>> Why?
>>> <
>>> A Bytecode interpreter, even in HW will have a serious performance
>>> issue when compared to a cross compiling native instruction set.
>>> Probably around 2×-3× penalty.
>>
>> Of course, the latency of the first-time compilation is somewhat
>> large :-)
>>
>> It is interesting to read the claims about picojava, which are
>> (unfortunately) not substantiated anywhere where I can get
>> to without a paywall.
>
> 1997 paper by Sun engineers on picoJava uArch and benchmarks says
> it was 15-20 times faster than a 486/33 running interpreter,
> and about 7-10 times faster than JIT.
>
> picoJava-I: The Java Virtual Machine in Hardware, 1997
> https://tsunami.zaibatsutel.net/liberez/picojava.pdf

And apparently this was a simulated piocJava core
vs real 486/33 and a Pentium/166.

On Monday, September 6, 2021 at 10:51:25 AM UTC-5, Anton Ertl wrote:
> Stefan Monnier <mon...@iro.umontreal.ca> writes:
> >> I see no unsurmountable hurdles to create a JavaVM front end for an
> >> appropriate OoO machine that produces a similar utilization of the FUs
> >> of the OoO machine. Note that there is no aliasing problem wrt the
> >> locals slots on the JavaVM.
> >
> >Whether a JVM CPU is possible (and even efficient) is probably
> >a hypothetical question at this point. The main question is: where's
> >the market for it?
> A lot of code is written in Java, so if a hardware JavaVM
> implementation provides a significant advantage for that, there should
> be a big market (possibly as additional decoder for otherwise
> general-purpose hardware, or by adding instructions for missing C
> operations to the JavaVM instruction set).
> >Reminds me of the Lisp machines,
> I think in this case you need to analyse the actual factors involved.
>
> Lisp Machines came out of the 1970s when bit-slice technology made it
> relatively cheap (in manpower) to design a CPU, and they provided an
> advantage in e.g., tag-handling and cdr-handling, and were faster at
> that than other CPUs done in similar technology. But the RISC
> revolution killed both the other CPUs done in similar technology and
> Lisp machines (and one of the AI winter's helped the demise along).
> RISCs with small extensions that can be useful for implementing Lisp
> were developed: SOAR on the academic level, and some of that went into
> SPARC on the commercial level.
>
> The JavaVM hardware efforts (picoJava, Jazelle DBX) were done in the
> late 1990s when Java JIT compilers did not play a role (at least when
> the projects were started). Jazelle DBX was a front end for an ARM9
> (not ARM v9), a single-issue in-order CPU; not much is known about
> picoJava (it never became a product), but given the other designs that
> Sun did at the time, I don't expect it to be OoO, and probably not
> superscalar, either (with in-order, superscalar stack machines are
> hard). This was in a world where OoO CPUs were winning and in
> particular Intel and AMD were into the GHz race and crushed basically
> all other architectures in the process, presumably not because of the
> superior architecture, but because of superior microarchitecture,
> superior circuit design, and maybe also superior process technology.
<
Java byte code is stack based, to JVM would have to execute 3-4 byte
code instructions per cycle to be in the same ball park as a GBOoO
machine executing 1 instruction per cycle. JIT is the better path.
>
> These days, we do not see much generational speedup, so architectural
> differences can play a bigger role now. You can afford to spend a
> year more on designing a CPU if it gives you 20% speedup (in the 1990s
> this would have been the recipe for defeat), although it's still
> better to releas the slow version now and the improved version in a
> year.
<
A 20% speedup in JVM in HW still leaves JVM a factor of 2.5× behind JIT
to native ISA.
<
> OTOH, designing a competetive microarchitecture is a pretty big
> task these days, it's not like in the Lisp Machine days. So if a
> hardware JavaVM has an advantage in some market over a conventional
> architecture and a JIT, the chances are probably much better now than
> they were in 1985-2005. The question is if the "if" is satisfied.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Monday, September 6, 2021 at 11:23:20 AM UTC-5, gareth evans wrote:
> On 06/09/2021 17:16, MitchAlsup wrote:
> > Which is why the JIT should have write only access to the area
> > it keeps compiled code, and the consumer of that code have
> > execute only access.
> Suggesting that the running application and the JIT compiler
> run as coroutines
<
Separate address spaces.

On 9/6/2021 8:25 AM, Anton Ertl wrote:
> gareth evans <headstone255@yahoo.com> writes:
>> This seems like a recipe for viruses!
>
> This sentence *is* a recipe for security theatre.
>

Meanwhile, am I like the only person with an ISA who has stuff like (?):
Memory that is RWX for the kernel, but R-X or --X for usermode;
Memory that is RW- for the kernel, but R-- for usermode;
...

This is before getting to the keyring, which can also be like:
VM program thread sees the memory as R-X;
JIT compiler thread sees the memory as RW-;
...

Though, the (more recent) addition of separate User and Supervisor
access is a bit limited/hacky given there weren't any free bits, so some
level of twiddly was used.

Likewise, say:
Task register (TBR) points to an area which is Read-Only from usermode,
but Read/Write to the kernel, pointing to another region which is
Read/Write from usermode (TLS variables and similar go here), and to a
region which is inaccessible from usermode (holds system-level state).

....

Granted, some of this stuff only works from usermode and with the MMU
enabled, where currently I only have the MME enabled if a swapfile was
found. This may change (with the MMU always being enabled after
boot-up), given I seem to now have the MMU relatively stable.

Even without a pagefile, the MMU could still allow for things like
remapping pages, growable stacks, ... It would also allow for usermode
programs to be less subject to the issues of RAM fragmentation.

At present, paged virtual memory is still mostly untested and fairly
incomplete (it also bypasses the normal filesystem code and requires the
swapfile to be contiguous on the SDcard). The use of a swapfile (rather
than a swap partition) being mostly because I didn't have a good way to
create such a partition via the Windows tools.

....

On 2021-09-06 09:44, Stefan Monnier wrote:
>> I see no unsurmountable hurdles to create a JavaVM front end for an
>> appropriate OoO machine that produces a similar utilization of the FUs
>> of the OoO machine. Note that there is no aliasing problem wrt the
>> locals slots on the JavaVM.
>
> Whether a JVM CPU is possible (and even efficient) is probably
> a hypothetical question at this point. The main question is: where's
> the market for it?

Well, billions of UICC devices (called sim cards) would be a lucrative
market.

Sun specified picoJava [sic] years ago but never released a product and
it never took off. Nowadays, there is Jazelle on ARM and the Atmel
AT90SC is fast enough so the JVM-on-silicon ship has probably sailed.

N.

>
> Reminds me of the Lisp machines,
>
>
> Stefan
>

On 9/6/2021 11:25 AM, MitchAlsup wrote:
> On Monday, September 6, 2021 at 11:23:20 AM UTC-5, gareth evans wrote:
>> On 06/09/2021 17:16, MitchAlsup wrote:
>>> Which is why the JIT should have write only access to the area
>>> it keeps compiled code, and the consumer of that code have
>>> execute only access.
>> Suggesting that the running application and the JIT compiler
>> run as coroutines
> <
> Separate address spaces.
>

IMO: It is better if one can give different sub-tasks different access
to pages within a single address space.

Granted, most existing OS API's (such as mmap/mprotect), or programs,
will have no idea of such a thing. One can add a bunch of new PROT_*
flags / macros, but most programs (probably) wont use them...

Nemo wrote:
> On 2021-09-06 09:44, Stefan Monnier wrote:
>>> I see no unsurmountable hurdles to create a JavaVM front end for an
>>> appropriate OoO machine that produces a similar utilization of the FUs
>>> of the OoO machine. Note that there is no aliasing problem wrt the
>>> locals slots on the JavaVM.
>>
>> Whether a JVM CPU is possible (and even efficient) is probably
>> a hypothetical question at this point. The main question is: where's
>> the market for it?
>
> Well, billions of UICC devices (called sim cards) would be a lucrative
> market.
>
> Sun specified picoJava [sic] years ago but never released a product and
> it never took off. Nowadays, there is Jazelle on ARM and the Atmel
> AT90SC is fast enough so the JVM-on-silicon ship has probably sailed.
>
> N.

Blu-ray requires all disc players to include Java software environment
as mandatory part of its standard called BD-J.

It was one of the reasons early Blu-ray players were so frigging slow
and expensive compared to normal DVD players. To run JVM they needed
a 32-bit processor with sophisticated OS like Linux.

If picoJava could have snagged that market...

On Monday, September 6, 2021 at 12:14:38 PM UTC-5, EricP wrote:
> Nemo wrote:
> > On 2021-09-06 09:44, Stefan Monnier wrote:
> >>> I see no unsurmountable hurdles to create a JavaVM front end for an
> >>> appropriate OoO machine that produces a similar utilization of the FUs
> >>> of the OoO machine. Note that there is no aliasing problem wrt the
> >>> locals slots on the JavaVM.
> >>
> >> Whether a JVM CPU is possible (and even efficient) is probably
> >> a hypothetical question at this point. The main question is: where's
> >> the market for it?
> >
> > Well, billions of UICC devices (called sim cards) would be a lucrative
> > market.
> >
> > Sun specified picoJava [sic] years ago but never released a product and
> > it never took off. Nowadays, there is Jazelle on ARM and the Atmel
> > AT90SC is fast enough so the JVM-on-silicon ship has probably sailed.
> >
> > N.
> Blu-ray requires all disc players to include Java software environment
> as mandatory part of its standard called BD-J.
>
> It was one of the reasons early Blu-ray players were so frigging slow
> and expensive compared to normal DVD players. To run JVM they needed
> a 32-bit processor with sophisticated OS like Linux.
>
> If picoJava could have snagged that market...
<
Which only reinforces the notion that that ship has sailed.

On Monday, September 6, 2021 at 11:49:41 AM UTC-5, BGB wrote:
> On 9/6/2021 8:25 AM, Anton Ertl wrote:
> > gareth evans <headst...@yahoo.com> writes:
> >> This seems like a recipe for viruses!
> >
> > This sentence *is* a recipe for security theatre.
> >
> Meanwhile, am I like the only person with an ISA who has stuff like (?):
> Memory that is RWX for the kernel, but R-X or --X for usermode;
> Memory that is RW- for the kernel, but R-- for usermode;
> ...
No.
>
>
> This is before getting to the keyring, which can also be like:
> VM program thread sees the memory as R-X;
> JIT compiler thread sees the memory as RW-;
> ...
>
> Though, the (more recent) addition of separate User and Supervisor
> access is a bit limited/hacky given there weren't any free bits, so some
> level of twiddly was used.
>
>
> Likewise, say:
> Task register (TBR) points to an area which is Read-Only from usermode,
> but Read/Write to the kernel, pointing to another region which is
> Read/Write from usermode (TLS variables and similar go here), and to a
> region which is inaccessible from usermode (holds system-level state).
>
> ...
>
>
> Granted, some of this stuff only works from usermode and with the MMU
> enabled, where currently I only have the MME enabled if a swapfile was
> found. This may change (with the MMU always being enabled after
> boot-up), given I seem to now have the MMU relatively stable.
>
> Even without a pagefile, the MMU could still allow for things like
> remapping pages, growable stacks, ... It would also allow for usermode
> programs to be less subject to the issues of RAM fragmentation.
>
> At present, paged virtual memory is still mostly untested and fairly
> incomplete (it also bypasses the normal filesystem code and requires the
> swapfile to be contiguous on the SDcard). The use of a swapfile (rather
> than a swap partition) being mostly because I didn't have a good way to
> create such a partition via the Windows tools.
>
> ...