Maybe this report is about a feature that is on the jacobin TO-DO list? If so, pardon my jumping the gun.

Tree-top: scimark2_java, cloned from https://github.com/texadactyl/scimark2_java. ls -R

.:
jnt  LICENSE  original_README.txt  README.md

./jnt:
Bench  scimark2

./jnt/Bench:
Applet.java  Bench.java  Formatter.java  HTTPPost.java  Plotter.java  SendMail.java  Stopwatch.java  SubmitDialog.java  Target.java

./jnt/scimark2:
applet.java        commandline.java  Constants.java  FFT.java     kernel.class  LU.class  MonteCarlo.class  Random.class  SOR.class  SparseCompRow.class  Stopwatch.class
commandline.class  Constants.class   FFT.class       Jacobi.java  kernel.java   LU.java   MonteCarlo.java   Random.java   SOR.java   SparseCompRow.java   Stopwatch.java

Compile: javac -O jnt/scimark2/commandline.java

Run the original jvm: java jnt.scimark2.commandline

SciMark 2.0a, elasped time = 27.23s
URL: https://math.nist.gov/scimark2/index.html

Composite Score: 2901.249182054803
FFT (1024): 2033.507015924168
SOR (100x100):   1887.3214307438175
Monte Carlo : 1655.731504772598
Sparse matmult (N=1000, nz=5000): 2590.355516411772
LU (100x100): 6339.33044242166

java.vendor: Private Build
java.version: 11.0.15
java..vm.vendor: Private Build
java.vm.version: 11.0.15+10-Ubuntu-0ubuntu0.22.04.1
os.arch: amd64
os.name: Linux
os.version: 5.15.0-41-generic

Run jacobin (compiled with go 1.8): jacobin jnt.scimark2.commandline

Jacobin VM v. 0.1.0, © 2021-2 by Andrew Binstock. All rights reserved. MPL 2.0 License.
jnt.scimark2.commandline is not a recognized option. Ignored.

Version information: openjdk version "11.0.15" 2022-04-19 x64 Xubuntu 22.04 LTS

The test is TestPrintOfCPpart2() in cpParser_test.go, which simply dumps the previously parsed constant pool (CP) entries to stderr.

After adding some diagnostic info, got this, which is incorrect b/c it does not show the final two CP entries correctly, which are a dynamic and at UTF8 entry (from Github build and test #221)

    cpParser_test.go:867: dynamic CP entry did not appear in logging of CP contents:
        Number of CP entries parsed: 08
        CP entry: 00, type 00 (dummy entry)
        CP entry: 01, type 16 (method type)      description index: 4370
        CP entry: 02, type 18 (invokedynamic)    boostrap index: 4616, name and type: 4609
        CP entry: 03, type 01 (UTF-8 string)     Module
        CP entry: 04, type 19 (module name)      Module
        CP entry: 05, type 20 (package name)     Module
        CP entry: 06, type 00 (dummy entry)
        CP entry: 07, type 00 (dummy entry)

The correct output should be:

Number of CP entries parsed: 08
CP entry: 00, type 00 (dummy entry)
CP entry: 01, type 16 (method type)      description index: 4370
CP entry: 02, type 18 (invokedynamic)    boostrap index: 4616, name and type: 4609
CP entry: 03, type 01 (UTF-8 string)     Module
CP entry: 04, type 19 (module name)      Module
CP entry: 05, type 20 (package name)     Module
CP entry: 06, type 17 (dynamic)          boostrap index: 4616, name and type: 4609
CP entry: 07, type 01 (UTF-8 string)     Hello

(Notice the difference in the last two entries.)

After removing the Module and Package entries to see whether they were causing the problem, got the following output (from build and test #222):

        cpParser_test.go:867: dynamic CP entry did not appear in logging of CP contents:
        Number of CP entries parsed: 06
        CP entry: 00, type 00 (dummy entry)
        CP entry: 01, type 16 (method type)      description index: 4370
        CP entry: 02, type 18 (invokedynamic)    boostrap index: 4616, name and type: 4609
        CP entry: 03, type 01 (UTF-8 string)     Module
        CP entry: 04, type 00 (dummy entry)
        CP entry: 05, type 00 (dummy entry) 

So, it's not the previous entries or their position that are causing the problem. Rather, it's the entries of themselves.

Note: This issue is logged as JACOBIN-86 on the internal Jacobin task list (kept on YouTrack)

Local mutex does not make sense

https://github.com/platypusguy/jacobin/blob/8818d325dae39b9a8a427359bd36ef330067e179/src/thread/jvmThread.go#L36

shouldn't it be

var addThreadToTableMutex = sync.Mutex{}
func AddThreadToTable(t *ExecThread, tbl *list.List) int {
	addThreadToTableMutex .Lock()

	tbl.PushBack(t)
	t.ID = tbl.Len() - 1
	addThreadToTableMutex .Unlock()

	return t.ID
}

One of the key components of a Java SE implementation is the Class Library. Currently, I only know that OpenJDK has a complete implementation of the Class Library. It is a little coupled to the Hotspot VM, however, other JVMs, like OpenJ9 can use it.

So my question is: Is one of the goals of this project reimplement the whole Java Class Library (like the java.lang.Object/java.util.HashMap, ...) or use the same as OpenJDK?

There are some other implementations of some components that wouldn't be required to be implemented, like using the ECJ for the compiler and Kodda for a replacement of Javadoc.

(The license of the JCL is GPL2, so it may play some role in the decision)

Adds support for JMOD files. Attempts to load java.base.jmod on startup, in order to replace the need for the JACOBIN_HOME setup. Test files are in testdata/jmod.

One note: I didn't end up looking for the classlist in $JAVA_HOME/lib, because this made it less applicable to other modules in the future and also complicated testing a bit. I don't think it is necessary, as the classlist file should be in the module at all times anyway, but I can add that functionality in if you think it is necessary?

As written, I believe that simultaneous threads will never wait because the mutex variable is local to functions being called.

Guessing from a Go newbie but I believe that you wanted to do something like this: https://notes.shichao.io/gopl/ch9/#mutual-exclusion-syncmutex and move the mutex definition to be global to the log package?

Those are the only 2 cases (logger.go:Log & main.go:shutdown) that I saw where there are mutexes being used.

This PR is based on my creating a temporary repo and testing uncommenting out the lines referenced in issue #1. Either I have the magic touch [(-;] or Unka Andoo's activity last night somehow cleansed something (?).

Built a simple .jar file from a manifest and 3 small class files.

++ java -jar specrel.jar

t_deltaAtRest: 10.0, x_lengthAtRest: 42.0
v: 0.1 * c, Time(s): 10.0 --> 10.05037815259212
	Length(m): 42.0 --> 41.78947235847804
v: 0.2 * c, Time(s): 10.0 --> 10.206207261596576
	Length(m): 42.0 --> 41.151427678757386
v: 0.30000000000000004 * c, Time(s): 10.0 --> 10.482848367219182
	Length(m): 42.0 --> 40.06544645951172
v: 0.4 * c, Time(s): 10.0 --> 10.910894511799619
	Length(m): 42.0 --> 38.49363583762906
v: 0.5 * c, Time(s): 10.0 --> 11.547005383792516
	Length(m): 42.0 --> 36.37306695894642
v: 0.6 * c, Time(s): 10.0 --> 12.5
	Length(m): 42.0 --> 33.6
v: 0.7 * c, Time(s): 10.0 --> 14.002800840280099
	Length(m): 42.0 --> 29.993999399879968
v: 0.7999999999999999 * c, Time(s): 10.0 --> 16.666666666666664
	Length(m): 42.0 --> 25.200000000000003
v: 0.8999999999999999 * c, Time(s): 10.0 --> 22.94157338705617
	Length(m): 42.0 --> 18.307375562870835


++ jacobin -jar specrel.jar

Invalid bytecode found: 20 at location 0 in method main() of class specrel/CommandLine

Error: could not find or load class specrel/Lorentz.
Error: could not find or load class specrel/Formulae.

See README.txt in the attached ZIP file for tree layout (small), bash scripts, and Java source files.

tinyjar.zip