Internal "native" `ByteBuffer`'s use `BIG_ENDIAN` `ByteOrder`; should use `nativeOrder` for speed...

[GordonBGood]

Description

It seems that Java's default is to consider everything to be stored as BIG_ENDIAN internally (most significant bytes at lower memory addresses); however, the actual machine interface works faster as far as the JIT'ed machine codes when emulated native buffers (ByteBuffer) are nativeOrder as then a single machine instruction can be used to read/write (or even read/modify/write) the various primitives of different byte lengths. The trick then is to determine the most optimum place to convert between this endedness. It seems that this conversion MUST be made in order for text conversion to work properly (at least currently).

So this issue is with attempting to implement ByteOrder nativeOrder for emulated native memory while allowing the text conversion system to work (and hopefully at least as efficiently) as it currently does.

Expected Behavior

No visible changes other than a gain in performance in handling the emulated native memory buffers.

Actual Behavior

A crash (at least on Windows) with an exception generated as follows:

Exception in thread "main" eta.runtime.exception.EtaException: mkTextEncoding: does not exist (unknown encoding:windows-1252)
        at base.ghc.TopHandler$runMainIO2.call(TopHandler.hs)
        at base.ghc.TopHandler$runMainIO2.apply1V(TopHandler.hs)
        at eta.runtime.exception.Exception.catch_(Exception.java:166)
        at main.Main$main3.call(Main.hs)
        at main.Main$DZCmain.call(Main.hs:4)
        at main.Main$DZCmain.applyV(Main.hs:4)
        at eta.runtime.stg.Closures$EvalLazyIO.enter(Closures.java:152)
        at eta.runtime.stg.Capability.schedule(Capability.java:246)
        at eta.runtime.stg.Capability.scheduleClosure(Capability.java:202)
        at eta.runtime.Runtime.evalLazyIO(Runtime.java:392)
        at eta.runtime.Runtime.main(Runtime.java:385)
        at eta.main.main(Unknown Source)
Caused by: eta.runtime.exception.EtaException: mkTextEncoding: does not exist (unknown encoding:windows-1252)
        at base.ghc.io.Encoding$getFileSystemEncoding5.call(Encoding.hs)
        at base.ghc.io.Encoding$initLocaleEncoding1.call(Encoding.hs)
        at base.ghc.io.Encoding$initLocaleEncoding.thunkEnter(Encoding.hs:156)
        at eta.runtime.thunk.CAF.evaluate(CAF.java:30)
        at base.ghc.io.handle.Internals$mkDuplexHandle9.call(Internals.hs:705)
        at base.ghc.io.handle.FD$$Llvl8$1.call(FD.hs)
        at base.ghc.io.handle.FD$stdout.thunkEnter(FD.hs:65)
        at eta.runtime.thunk.CAF.evaluate(CAF.java:30)
        at base.ghc.io.handle.Internals$wantWritableHandle1.call(Internals.hs:226)
        at base.ghc.io.handle.Text$hPutStr2.call(Text.hs)
        at main.Main$main1.call(Main.hs:4)
        at main.Main$main1.applyV(Main.hs)
        at eta.runtime.exception.Exception.catch_(Exception.java:129)
        ... 9 more

Possible Fix

Find the appropriate place in the text processing code to convert between nativeOrder and BIG_ENDIAN ByteOrder for utilized ByteBuffer's so this works but with a minimum cost in performance due to the conversions between endedness.

Steps to Reproduce

Modify the Eta run time source as per the attached .java files (with one related to labelling threads with a text field in concurrency), do a "eta-build rts-clean" (after having built Eta from source), and running any program that prints to the screen, such as the attached "HelloWorld" project.

Context

This is part of the speedups I am trying to accomplish related to array processing as per issue #940.

Your Environment

• Did you install an older version of Eta/Etlas before? Yes, I have had Etlas version 1.5.0.0 and Eta versions 0.8.6.b3 and 0.8.6.b4 installed before, but didn't modify the source in this way to seek these speed improvements until now.
• Current Eta & Etlas version: Etlas version 1.6.0.0 (HEAD?) and Eta version 0.8.6.5 (HEAD?)
• Operating System and version: Windows 10 64-bit Build 1809
• Modified files attached:
  ModifiedJavaFiles.zip
• Project zip attached:
  eta-helloworld.zip

[rahulmutt]

@jneira This looks like it's related to your work on HSIConv.java - can you take a look at where endianess is assumed and adjust accordingly?

@GordonBGood I think beyond the base library, several other libraries will have to be changed to ensure that endianness is preserved. Perhaps even the use of big endianness is assumed in some places in the MemoryManager as well. A thorough code review needs to be done, but this is a great start.

[GordonBGood]

@rahulmutt, I think you'll find that "MemoryManager.java" is one of the files that I enclosed a changed version, and yes, it does need some small changes.

I've done a search through the repo and see that "HSIConv.java" is the main point of contact between Eta MemoryManager and the decoding of chars; from there, the work is done by the Java encoder/decoder classes and whatever they assume. But I don't think that is even the problem; I think the problem is the interface between text to/fro the OS, where ever that is...

Someone who deals with that part should know what the main point of contact is.