Jython (JVM Python)
-------------------

Make sure you got Java installed, grab vmsscript-bin.zip here
https://www.vajhoej.dk/arne/opensource/vms/,
unzip vmsscript-bin.zip, unzip -aa temp.zip, @fixup.

Seems to work fine (ignore warning about InteractiveConsole).

Rhino (JVM JavaScript)
----------------------

Make sure you got Java installed, grab vmsscript-bin.zip here
https://www.vajhoej.dk/arne/opensource/vms/,
unzip vmsscript-bin.zip, unzip -aa temp.zip, @fixup.

Seems to work fine.

Groovy
------

Make sure you got Java installed, grab latest 4.0.x standard zip,
unzip (ODS-5 of course), grab groovy.com and groovydef.com here
https://www.vajhoej.dk/arne/vms/snippets/ (extension is changed
to .txt to make browser display).

Seems to work fine.

Scala
-----

Make sure you got Java installed, grab latest 2.13.x standard zip,
unzip (ODS-5 of course), grab scala.com and scaladef.com here
https://www.vajhoej.dk/arne/vms/snippets/ (extension is changed
to .txt to make browser display).

Seems to work fine.

Kotlin
------

Make sure you got Java installed, grab latest 1.9.x standard zip,
unzip (ODS-5 of course), grab kotlin.com and kotlindef.com here
https://www.vajhoej.dk/arne/vms/snippets/ (extension is changed
to .txt to make browser display).

Works with a few hassles:
* the compiler does not recognize .KT files as Kotlin
source only .kt so one need to quote the filename
as argument to the wrapper COM file aka kotlinc "test.kt"
* the compiler only works with source files in RFM STMLF

Arne

On Wednesday, 18 October 2023 at 18:01:12 UTC+1, Arne Vajhøj wrote:
> Jython (JVM Python)
> -------------------
>
> Make sure you got Java installed, grab vmsscript-bin.zip here
> https://www.vajhoej.dk/arne/opensource/vms/,
> unzip vmsscript-bin.zip, unzip -aa temp.zip, @fixup.
>
> Seems to work fine (ignore warning about InteractiveConsole).
>
> Rhino (JVM JavaScript)
> ----------------------
>
> Make sure you got Java installed, grab vmsscript-bin.zip here
> https://www.vajhoej.dk/arne/opensource/vms/,
> unzip vmsscript-bin.zip, unzip -aa temp.zip, @fixup.
>
> Seems to work fine.
>
> Groovy
> ------
>
> Make sure you got Java installed, grab latest 4.0.x standard zip,
> unzip (ODS-5 of course), grab groovy.com and groovydef.com here
> https://www.vajhoej.dk/arne/vms/snippets/ (extension is changed
> to .txt to make browser display).
>
> Seems to work fine.
>
> Scala
> -----
>
> Make sure you got Java installed, grab latest 2.13.x standard zip,
> unzip (ODS-5 of course), grab scala.com and scaladef.com here
> https://www.vajhoej.dk/arne/vms/snippets/ (extension is changed
> to .txt to make browser display).
>
> Seems to work fine.
>
>
> Kotlin
> ------
>
> Make sure you got Java installed, grab latest 1.9.x standard zip,
> unzip (ODS-5 of course), grab kotlin.com and kotlindef.com here
> https://www.vajhoej.dk/arne/vms/snippets/ (extension is changed
> to .txt to make browser display).
>
> Works with a few hassles:
> * the compiler does not recognize .KT files as Kotlin
> source only .kt so one need to quote the filename
> as argument to the wrapper COM file aka kotlinc "test.kt"
> * the compiler only works with source files in RFM STMLF
>
> Arne

Nice work!

What system and account quotas do you recommend for Groovy? I'm getting the following with the simple test script...

#
# There is insufficient memory for the Java Runtime Environment to continue..
# Native memory allocation (malloc) failed to allocate 34078720 bytes for PSYoun
gGen::resize_generation

Re quotas then to get it to run just make sure PGFLQUO is larger
than Xmx.

So -Xmx256m should be fine with PGFLQUO of 750000, -Xmx512m with
1500000, -Xmx1024m with 3000000 etc..

(50% spare is probably too much spare, but better too much
than too little)

To get it run well I assume WSEXT should also be raised.

Arne

On Thursday, 19 October 2023 at 01:56:30 UTC+1, Arne Vajhøj wrote:
> Re quotas then to get it to run just make sure PGFLQUO is larger
> than Xmx.
>
> So -Xmx256m should be fine with PGFLQUO of 750000, -Xmx512m with
> 1500000, -Xmx1024m with 3000000 etc..
>
> (50% spare is probably too much spare, but better too much
> than too little)
>
> To get it run well I assume WSEXT should also be raised.
>
> Arne

Thanks, working now as per your tests for GROOVY and GROOVYC

Not having much luck with Groovy Shell though, does this work for you?

$ groovysh --help
java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main
at org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:180)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:148)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter..java
:109)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)

On Thursday, 19 October 2023 at 09:44:57 UTC+1, issinoho wrote:
> On Thursday, 19 October 2023 at 01:56:30 UTC+1, Arne Vajhøj wrote:
> > Re quotas then to get it to run just make sure PGFLQUO is larger
> > than Xmx.
> >
> > So -Xmx256m should be fine with PGFLQUO of 750000, -Xmx512m with
> > 1500000, -Xmx1024m with 3000000 etc..
> >
> > (50% spare is probably too much spare, but better too much
> > than too little)
> >
> > To get it run well I assume WSEXT should also be raised.
> >
> > Arne
> Thanks, working now as per your tests for GROOVY and GROOVYC
>
> Not having much luck with Groovy Shell though, does this work for you?
>
> $ groovysh --help
> java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main
> at org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:180)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:148)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
> :109)
> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)

Also, Scala seems to need more resources than Groovy, as with...
WSextent: 65536
Pgflquo: 750000
-Xmx256m

(which Groovy is happy with) I'm getting...

$ scala test.scala
# # There is insufficient memory for the Java Runtime Environment to continue..
# Native memory allocation (malloc) failed to allocate 39321600 bytes for PSOldG
en::expand_to_reserved
# An error report file with more information is saved as:
# /sys$scratch//hs_err_pid30232.log

On Thu, 2023-10-19 at 01:44 -0700, issinoho wrote:
> Not having much luck with Groovy Shell though, does this work for
> you?

At a guess it probably needs to know where to find its class files.
--
Tactical Nuclear Kittens

On Thursday, October 19, 2023 at 2:08:29 AM UTC-7, issinoho wrote:
> On Thursday, 19 October 2023 at 09:44:57 UTC+1, issinoho wrote:
> > On Thursday, 19 October 2023 at 01:56:30 UTC+1, Arne Vajhøj wrote:
> > > Re quotas then to get it to run just make sure PGFLQUO is larger
> > > than Xmx.
> > >
> > > So -Xmx256m should be fine with PGFLQUO of 750000, -Xmx512m with
> > > 1500000, -Xmx1024m with 3000000 etc..
> > >
> > > (50% spare is probably too much spare, but better too much
> > > than too little)
> > >
> > > To get it run well I assume WSEXT should also be raised.
> > >
> > > Arne
> > Thanks, working now as per your tests for GROOVY and GROOVYC
> >
> > Not having much luck with Groovy Shell though, does this work for you?
> >
> > $ groovysh --help
> > java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main
> > at org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:180)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> > at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:148)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> > at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
> > :109)
> > at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)
> Also, Scala seems to need more resources than Groovy, as with...
> WSextent: 65536
> Pgflquo: 750000
> -Xmx256m
>
> (which Groovy is happy with) I'm getting...
>
> $ scala test.scala
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 39321600 bytes for PSOldG
> en::expand_to_reserved
> # An error report file with more information is saved as:
> # /sys$scratch//hs_err_pid30232.log

Your Pgflquo is only 366 MiB, which isn't going to be enough for the JVM. Even though you've limited the max heap size to 256 MiB, the allocated virtual memory could be around double that, with JIT caches, so the out-of-memory error you're seeing isn't unexpected with your quotas.

For my latest round of Java benchmarking, I've increased the system WSMAX, along with my WSextent, to 12582912 pagelets (6 GiB), and I've increased my user Pgflquo to 33554432 pagelets (16 GiB), the size of the VM's RAM.

Everything did work using a WSextent of just under 2 GiB, and a Pgflquo of 10000000 pagelets (4.77 GiB), but I wanted to boost the working set to be as large as possible so my Java VMs aren't getting page faults for no reason, and in anticipation of some large RAM benchmarks I may want to do later.

The reason I wasn't able to set WSextent to 6 GiB before was that there's a bug in the x86 version of AUTOGEN that was just fixed in the VMS921X_UPDATE-V0200 patch that was just posted to the VSI portal. One of the bug fixes was for miscalculation of the parameters under circumstances like trying to set MIN_WSMAX to 2 GiB or higher. With that patch applied, I had no trouble setting it to 6 GiB, and SYSMAN says that the max value is currently 64 GiB.

I generally don't see Java apps using higher than -Xmx2048m, but that's going to mean the process is allocating as much as 4 GiB or more virtual memory, with a working set size of hopefully around 2 GiB, so with today's typical large memory VMs, there's no reason not to increase WSextent and Pgflquo to let the JVM take full advantage.

Regards,
Jake Hamby

On 10/19/2023 5:08 AM, issinoho wrote:
> Also, Scala seems to need more resources than Groovy, as with...
> WSextent: 65536
> Pgflquo: 750000
> -Xmx256m
>
> (which Groovy is happy with) I'm getting...
>
> $ scala test.scala
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 39321600 bytes for PSOldG
> en::expand_to_reserved
> # An error report file with more information is saved as:
> # /sys$scratch//hs_err_pid30232.log

Then just double.

-Xmx512m
PGFQUO 1500000

And try again.

-Xmx256m worked for my hello world style scala program, but my PGFLQUO
is a lot higher.

Arne

On 10/19/2023 4:44 AM, issinoho wrote:
> Thanks, working now as per your tests for GROOVY and GROOVYC
>
> Not having much luck with Groovy Shell though, does this work for you?
>
> $ groovysh --help
> java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main
> at org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:180)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:148)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
> :109)
> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)

Ooops. I did not test groovysh.

Looks like they changed the class name from:
org.codehaus.groovy.tools.shell.Main
to:
org.codehaus.groovy.tools.shell.Main
in recent Groovy versions.

But just changing:

$ if p1 .eqs. "SHELL" then clz = "org.codehaus.groovy.tools.shell.Main"

to:

$ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"

Does not make it work.

The new shell use jline and jline got this idea that spawning
sh to change terminal attributes is a portable approach.

Jython had the same problem, but there were a workaround.

I will have to look more into this.

Arne

On 10/19/2023 4:16 PM, Arne Vajhøj wrote:
> On 10/19/2023 4:44 AM, issinoho wrote:
>> Thanks, working now as per your tests for GROOVY and GROOVYC
>>
>> Not having much luck with Groovy Shell though, does this work for you?
>>
>> $ groovysh --help
>> java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main
>>          at
>> org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:180)
>>          at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>>          at
>> org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:148)
>>          at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>>          at
>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
>> :109)
>>          at
>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)
>
> Ooops. I did not test groovysh.
>
> Looks like they changed the class name from:
>   org.codehaus.groovy.tools.shell.Main
> to:
>   org.codehaus.groovy.tools.shell.Main
> in recent Groovy versions.
>
> But just changing:
>
> $ if p1 .eqs. "SHELL" then clz = "org.codehaus.groovy.tools.shell.Main"
>
> to:
>
> $ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
>
>
> Does not make it work.
>
> The new shell use jline and jline got this idea that spawning
> sh to change terminal attributes is a portable approach.
>
> Jython had the same problem, but there were a workaround.
>
> I will have to look more into this.

Could you try with:

$ p1 = f$edit(p1, "UPCASE")
$ clz = ""
$ if p1 .eqs. "RUN" then clz = "groovy.ui.GroovyMain"
$ if p1 .eqs. "COMPILE" then clz =
"org.codehaus.groovy.tools.FileSystemCompiler"
$ if p1 .eqs. "CONSOLE" then clz = groovy.ui.Console"
$ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
$ parent = "/disk2/arne/groovy"
$ ver = "4.0.12"
$ groovyhome = "''parent'/groovy-''ver'"
$ xmx = "''groovy_xmx'"
$ if xmx .eqs. "" then xmx = "256m"
$ cp = "''groovy_cp'"
$ if cp .eqs. "" then cp = "."
$ define/nolog sys$input sys$command
$ java -
"-Xmx''xmx'" -
"-Dprogram.name"="" -
"-Dgroovy.home"="''groovyhome'" -
"-Dtools.jar"="/sys$sysdevice/sys0/syscommon/java$80/lib/tools.jar" -
"-Dgroovy.starter.conf"="''groovyhome'/conf/groovy-starter.conf" -
"-Dscript.name"="''p2'" -
-classpath "''groovyhome'/lib/groovy-''ver'.jar" -
"org.codehaus.groovy.tools.GroovyStarter" -
--main "''clz'" -
--conf "''groovyhome'/conf/groovy-starter.conf" -
--classpath "''cp'" -
"--terminal=none" -
'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'
$ if p1 .eqs. "COMPILE" then write sys$output "Run with java -cp
..:''groovyhome'/lib/* <main-class>"
$ exit

Arne

On Thu, 2023-10-19 at 16:16 -0400, Arne Vajhøj wrote:
> Looks like they changed the class name from:
>    org.codehaus.groovy.tools.shell.Main
> to:
>    org.codehaus.groovy.tools.shell.Main
> in recent Groovy versions.

Huh?
--
Tactical Nuclear Kittens

On 10/19/23 5:24 PM, Single Stage to Orbit wrote:
> On Thu, 2023-10-19 at 16:16 -0400, Arne Vajhøj wrote:
>> Looks like they changed the class name from:
>>    org.codehaus.groovy.tools.shell.Main
>> to:
>>    org.codehaus.groovy.tools.shell.Main
>> in recent Groovy versions.

He just had a typo -- from the rest of his message it looks like the
second one should be:

org.apache.groovy.groovysh.Main

On 10/19/2023 6:39 PM, Craig A. Berry wrote:
> On 10/19/23 5:24 PM, Single Stage to Orbit wrote:
>> On Thu, 2023-10-19 at 16:16 -0400, Arne Vajhøj wrote:
>>> Looks like they changed the class name from:
>>>     org.codehaus.groovy.tools.shell.Main
>>> to:
>>>     org.codehaus.groovy.tools.shell.Main
>>> in recent Groovy versions.
>
> He just had a typo --

Copy paste error.

> from the rest of his message it looks like the
> second one should be:
>
> org.apache.groovy.groovysh.Main

Yes.

Arne

On Thursday, October 19, 2023 at 1:05:36 PM UTC-7, Arne Vajhøj wrote:
> On 10/19/2023 5:08 AM, issinoho wrote:
> > Also, Scala seems to need more resources than Groovy, as with...
> > WSextent: 65536
> > Pgflquo: 750000
> > -Xmx256m
> >
> > (which Groovy is happy with) I'm getting...
> >
> > $ scala test.scala
> > #
> > # There is insufficient memory for the Java Runtime Environment to continue.
> > # Native memory allocation (malloc) failed to allocate 39321600 bytes for PSOldG
> > en::expand_to_reserved
> > # An error report file with more information is saved as:
> > # /sys$scratch//hs_err_pid30232.log
> Then just double.
>
> -Xmx512m
> PGFQUO 1500000
>
> And try again.
>
> -Xmx256m worked for my hello world style scala program, but my PGFLQUO
> is a lot higher.
>
> Arne

For the record, the default JVM heap size in the current OpenJDK 8 x86-64 port is 3.50 GB, at least for a VM with 16 GB RAM:

$ java -XshowSettings:vm
VM settings:
Max. Heap Size (Estimated): 3.50G
Ergonomics Machine Class: server
Using VM: OpenJDK 64-Bit Server VM
$ java -version
openjdk version "1.8.0_372"
OpenJDK Runtime Environment (build 1.8.0_372-b07)
OpenJDK 64-Bit Server VM (build 25.372-b07, mixed mode)

After running all of the Renaissance JVM benchmarks, which stressed the JVM to its limit, "show proc/acc" showed usage of:

Peak working set size: 6634496 pagelets = 3240 MiB
Peak virtual size: 10359200 pagelets = 5058 MiB

So my previous post about pgflquo needing to be nearly twice as high as the heap size was demonstrated by the accounting data, and the peak working set size was indeed just under the max Java heap size.

I wonder if VSI should consider increasing the AUTOGEN-generated WSMAX to something more appropriate for the amount of RAM in the VM, and for use cases such as the JVM that expect to have large working sets and peak virtual sizes by default.

Regards,
Jake Hamby

On 10/19/2023 4:34 PM, Arne Vajhøj wrote:
> On 10/19/2023 4:16 PM, Arne Vajhøj wrote:
>> On 10/19/2023 4:44 AM, issinoho wrote:
>>> Thanks, working now as per your tests for GROOVY and GROOVYC
>>>
>>> Not having much luck with Groovy Shell though, does this work for you?
>>>
>>> $ groovysh --help
>>> java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main
>>>          at
>>> org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:180)
>>>          at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>>>          at
>>> org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:148)
>>>          at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>>>          at
>>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
>>> :109)
>>>          at
>>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)
>>
>> Ooops. I did not test groovysh.
>>
>> Looks like they changed the class name from:
>>    org.codehaus.groovy.tools.shell.Main
>> to:
>>    org.codehaus.groovy.tools.shell.Main
>> in recent Groovy versions.
>>
>> But just changing:
>>
>> $ if p1 .eqs. "SHELL" then clz = "org.codehaus.groovy.tools.shell.Main"
>>
>> to:
>>
>> $ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
>>
>>
>> Does not make it work.
>>
>> The new shell use jline and jline got this idea that spawning
>> sh to change terminal attributes is a portable approach.
>>
>> Jython had the same problem, but there were a workaround.
>>
>> I will have to look more into this.
>
> Could you try with:
>
> $ p1 = f$edit(p1, "UPCASE")
> $ clz = ""
> $ if p1 .eqs. "RUN" then clz = "groovy.ui.GroovyMain"
> $ if p1 .eqs. "COMPILE" then clz =
> "org.codehaus.groovy.tools.FileSystemCompiler"
> $ if p1 .eqs. "CONSOLE" then clz = groovy.ui.Console"
> $ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
> $ parent = "/disk2/arne/groovy"
> $ ver = "4.0.12"
> $ groovyhome = "''parent'/groovy-''ver'"
> $ xmx = "''groovy_xmx'"
> $ if xmx .eqs. "" then xmx = "256m"
> $ cp = "''groovy_cp'"
> $ if cp .eqs. "" then cp = "."
> $ define/nolog sys$input sys$command
> $ java -
> "-Xmx''xmx'" -
> "-Dprogram.name"="" -
> "-Dgroovy.home"="''groovyhome'" -
> "-Dtools.jar"="/sys$sysdevice/sys0/syscommon/java$80/lib/tools.jar" -
> "-Dgroovy.starter.conf"="''groovyhome'/conf/groovy-starter.conf" -
> "-Dscript.name"="''p2'" -
> -classpath "''groovyhome'/lib/groovy-''ver'.jar" -
> "org.codehaus.groovy.tools.GroovyStarter" -
> --main "''clz'" -
> --conf "''groovyhome'/conf/groovy-starter.conf" -
> --classpath "''cp'"  -
> "--terminal=none" -
> 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'
> $ if p1 .eqs. "COMPILE" then write sys$output "Run with java -cp
> .:''groovyhome'/lib/* <main-class>"
> $ exit

That broke the groovy command.

Once more:

$ p1 = f$edit(p1, "UPCASE")
$ clz = ""
$ if p1 .eqs. "RUN" then clz = "groovy.ui.GroovyMain"
$ if p1 .eqs. "COMPILE" then clz =
"org.codehaus.groovy.tools.FileSystemCompiler"
$ if p1 .eqs. "CONSOLE" then clz = groovy.ui.Console"
$ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
$ parent = "/disk2/arne/groovy"
$ ver = "4.0.12"
$ groovyhome = "''parent'/groovy-''ver'"
$ xmx = "''groovy_xmx'"
$ if xmx .eqs. "" then xmx = "256m"
$ cp = "''groovy_cp'"
$ if cp .eqs. "" then cp = "."
$ xtra = ""
$ if p1 .eqs. "SHELL" then xtra = "--terminal=none"
$ define/nolog sys$input sys$command
$ java -
"-Xmx''xmx'" -
"-Dprogram.name"="" -
"-Dgroovy.home"="''groovyhome'" -
"-Dtools.jar"="/sys$sysdevice/sys0/syscommon/java$80/lib/tools.jar" -
"-Dgroovy.starter.conf"="''groovyhome'/conf/groovy-starter.conf" -
"-Dscript.name"="''p2'" -
-classpath "''groovyhome'/lib/groovy-''ver'.jar" -
"org.codehaus.groovy.tools.GroovyStarter" -
--main "''clz'" -
--conf "''groovyhome'/conf/groovy-starter.conf" -
--classpath "''cp'" -
'xtra' -
'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'
$ if p1 .eqs. "COMPILE" then write sys$output "Run with java -cp
..:''groovyhome'/lib/* <main-class>"
$ exit

Arne

On Friday, 20 October 2023 at 02:07:30 UTC+1, Arne Vajhøj wrote:
> On 10/19/2023 4:34 PM, Arne Vajhøj wrote:
> > On 10/19/2023 4:16 PM, Arne Vajhøj wrote:
> >> On 10/19/2023 4:44 AM, issinoho wrote:
> >>> Thanks, working now as per your tests for GROOVY and GROOVYC
> >>>
> >>> Not having much luck with Groovy Shell though, does this work for you?
> >>>
> >>> $ groovysh --help
> >>> java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main
> >>> at
> >>> org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:180)
> >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> >>> at
> >>> org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:148)
> >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> >>> at
> >>> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
> >>> :109)
> >>> at
> >>> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)
> >>
> >> Ooops. I did not test groovysh.
> >>
> >> Looks like they changed the class name from:
> >> org.codehaus.groovy.tools.shell.Main
> >> to:
> >> org.codehaus.groovy.tools.shell.Main
> >> in recent Groovy versions.
> >>
> >> But just changing:
> >>
> >> $ if p1 .eqs. "SHELL" then clz = "org.codehaus.groovy.tools.shell.Main"
> >>
> >> to:
> >>
> >> $ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
> >>
> >>
> >> Does not make it work.
> >>
> >> The new shell use jline and jline got this idea that spawning
> >> sh to change terminal attributes is a portable approach.
> >>
> >> Jython had the same problem, but there were a workaround.
> >>
> >> I will have to look more into this.
> >
> > Could you try with:
> >
> > $ p1 = f$edit(p1, "UPCASE")
> > $ clz = ""
> > $ if p1 .eqs. "RUN" then clz = "groovy.ui.GroovyMain"
> > $ if p1 .eqs. "COMPILE" then clz =
> > "org.codehaus.groovy.tools.FileSystemCompiler"
> > $ if p1 .eqs. "CONSOLE" then clz = groovy.ui.Console"
> > $ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
> > $ parent = "/disk2/arne/groovy"
> > $ ver = "4.0.12"
> > $ groovyhome = "''parent'/groovy-''ver'"
> > $ xmx = "''groovy_xmx'"
> > $ if xmx .eqs. "" then xmx = "256m"
> > $ cp = "''groovy_cp'"
> > $ if cp .eqs. "" then cp = "."
> > $ define/nolog sys$input sys$command
> > $ java -
> > "-Xmx''xmx'" -
> > "-Dprogram.name"="" -
> > "-Dgroovy.home"="''groovyhome'" -
> > "-Dtools.jar"="/sys$sysdevice/sys0/syscommon/java$80/lib/tools.jar" -
> > "-Dgroovy.starter.conf"="''groovyhome'/conf/groovy-starter.conf" -
> > "-Dscript.name"="''p2'" -
> > -classpath "''groovyhome'/lib/groovy-''ver'.jar" -
> > "org.codehaus.groovy.tools.GroovyStarter" -
> > --main "''clz'" -
> > --conf "''groovyhome'/conf/groovy-starter.conf" -
> > --classpath "''cp'" -
> > "--terminal=none" -
> > 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'
> > $ if p1 .eqs. "COMPILE" then write sys$output "Run with java -cp
> > .:''groovyhome'/lib/* <main-class>"
> > $ exit
> That broke the groovy command.
>
> Once more:
> $ p1 = f$edit(p1, "UPCASE")
> $ clz = ""
> $ if p1 .eqs. "RUN" then clz = "groovy.ui.GroovyMain"
> $ if p1 .eqs. "COMPILE" then clz =
> "org.codehaus.groovy.tools.FileSystemCompiler"
> $ if p1 .eqs. "CONSOLE" then clz = groovy.ui.Console"
> $ if p1 .eqs. "SHELL" then clz = "org.apache.groovy.groovysh.Main"
> $ parent = "/disk2/arne/groovy"
> $ ver = "4.0.12"
> $ groovyhome = "''parent'/groovy-''ver'"
> $ xmx = "''groovy_xmx'"
> $ if xmx .eqs. "" then xmx = "256m"
> $ cp = "''groovy_cp'"
> $ if cp .eqs. "" then cp = "."
> $ xtra = ""
> $ if p1 .eqs. "SHELL" then xtra = "--terminal=none"
> $ define/nolog sys$input sys$command
> $ java -
> "-Xmx''xmx'" -
> "-Dprogram.name"="" -
> "-Dgroovy.home"="''groovyhome'" -
> "-Dtools.jar"="/sys$sysdevice/sys0/syscommon/java$80/lib/tools.jar" -
> "-Dgroovy.starter.conf"="''groovyhome'/conf/groovy-starter.conf" -
> "-Dscript.name"="''p2'" -
> -classpath "''groovyhome'/lib/groovy-''ver'.jar" -
> "org.codehaus.groovy.tools.GroovyStarter" -
> --main "''clz'" -
> --conf "''groovyhome'/conf/groovy-starter.conf" -
> --classpath "''cp'" -
> 'xtra' -
> 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'
> $ if p1 .eqs. "COMPILE" then write sys$output "Run with java -cp
> .:''groovyhome'/lib/* <main-class>"
> $ exit
>
> Arne

Thanks, everyone. Both Groovy and Scala now working nicely.

On 10/19/2023 8:55 PM, Jake Hamby (Solid State Jake) wrote:
> For the record, the default JVM heap size in the current OpenJDK 8 x86-64 port is 3.50 GB, at least for a VM with 16 GB RAM:

I believe the default should be 25% of RAM. Which matches your numbers
reasonable (it could deduct some RAM for some reason).

> $ java -XshowSettings:vm
> VM settings:
> Max. Heap Size (Estimated): 3.50G
> Ergonomics Machine Class: server
> Using VM: OpenJDK 64-Bit Server VM
> $ java -version
> openjdk version "1.8.0_372"
> OpenJDK Runtime Environment (build 1.8.0_372-b07)
> OpenJDK 64-Bit Server VM (build 25.372-b07, mixed mode)
>
> After running all of the Renaissance JVM benchmarks, which stressed the JVM to its limit, "show proc/acc" showed usage of:
>
> Peak working set size: 6634496 pagelets = 3240 MiB
> Peak virtual size: 10359200 pagelets = 5058 MiB
>
> So my previous post about pgflquo needing to be nearly twice as high
> as the heap size was demonstrated by the accounting data, and the
> peak working set size was indeed just under the max Java heap size.
It surprises me, but it looks that way.

My test:

$ javac -cp /vmsjavacallpath/vmscall.jar:/vmsjavacallpath/record.jar
MemAna.java
$ java "-Xms64m" "-Xmx768m" -cp
..:/vmsjavacallpath/vmscall.jar:/vmsjavacallpath/record.jar "MemAna"
Start : heap = 5476, wssize = 150592, pgcnt =
95168, usedpgfl = 242752
New 100000 pages : heap = 102760, wssize = 207712, pgcnt =
198256, usedpgfl = 393680
New 100000 pages : heap = 203644, wssize = 379072, pgcnt =
300288, usedpgfl = 615632
New 100000 pages : heap = 304870, wssize = 493312, pgcnt =
487280, usedpgfl = 866448
New 100000 pages : heap = 406151, wssize = 607552, pgcnt =
550800, usedpgfl = 1117248
New 100000 pages : heap = 507445, wssize = 778912, pgcnt =
551232, usedpgfl = 1368048
Back : heap = 7445, wssize = 778912, pgcnt =
551232, usedpgfl = 1368048
New 100000 pages : heap = 107060, wssize = 778912, pgcnt =
551088, usedpgfl = 1293008
New 100000 pages : heap = 206702, wssize = 778912, pgcnt =
550960, usedpgfl = 1223680
New 100000 pages : heap = 306702, wssize = 778912, pgcnt =
584352, usedpgfl = 1223680
New 100000 pages : heap = 406702, wssize = 836032, pgcnt =
646464, usedpgfl = 1223680
New 100000 pages : heap = 507446, wssize = 893152, pgcnt =
646976, usedpgfl = 1368048
Back : heap = 7445, wssize = 893152, pgcnt =
647216, usedpgfl = 1368048
New 100000 pages : heap = 107060, wssize = 893152, pgcnt =
647488, usedpgfl = 1293008
New 100000 pages : heap = 206703, wssize = 893152, pgcnt =
647360, usedpgfl = 1223680
New 100000 pages : heap = 306703, wssize = 893152, pgcnt =
647360, usedpgfl = 1223680
New 100000 pages : heap = 406714, wssize = 893152, pgcnt =
648800, usedpgfl = 1223680
New 100000 pages : heap = 507458, wssize = 893152, pgcnt =
649136, usedpgfl = 1368064
Back : heap = 7457, wssize = 893152, pgcnt =
649152, usedpgfl = 1368064

MemAna.java:

import java.io.UnsupportedEncodingException;
import java.util.Map;

import dk.vajhoej.record.RecordException;

import static dk.vajhoej.vms.call.lib.VMSCodes.*;
import static dk.vajhoej.vms.call.lib.VMSStatus.*;
import static dk.vajhoej.vms.call.lib.SYS.*;

public class MemAna {
private static void printStatus(String lbl) throws
UnsupportedEncodingException, RecordException {
System.gc();
Result<Map<Integer,Object>> res = SYS$GETJPIW(0, new int[] {
JPI$_WSSIZE,
JPI$_PPGCNT, JPI$_GPGCNT,
JPI$_PAGFILCNT, JPI$_PGFLQUOTA });
if(res.getStatus() == SS$_NORMAL) {
System.out.printf("%-20s: heap = %8d, wssize = %8d, pgcnt =
%8d, usedpgfl = %8d\n",
lbl,
(Runtime.getRuntime().totalMemory() -
Runtime.getRuntime().freeMemory()) / 512,
res.getResult().get(JPI$_WSSIZE),
(int)(Integer)res.getResult().get(JPI$_PPGCNT) +
(int)(Integer)res.getResult().get(JPI$_GPGCNT),
(int)(Integer)res.getResult().get(JPI$_PGFLQUOTA) -
(int)(Integer)res.getResult().get(JPI$_PAGFILCNT)
);
} else {
System.out.printf("sys$getjpiw returned: %d\n",
res.getStatus());
}
}
public static void main(String[] args) throws Exception {
printStatus("Start");
for(int i = 0; i < 3; i++) {
byte[] b1 = new byte[100000 * 512];
printStatus("New 100000 pages");
byte[] b2 = new byte[100000 * 512];
printStatus("New 100000 pages");
byte[] b3 = new byte[100000 * 512];
printStatus("New 100000 pages");
byte[] b4 = new byte[100000 * 512];
printStatus("New 100000 pages");
byte[] b5 = new byte[100000 * 512];
printStatus("New 100000 pages");
if(b1[0] != 0 || b2[0] != 0 || b3[0] != 0 || b4[0] != 0 ||
b5[0] != 0) throw new RuntimeException("Ooops");
b1 = null;
b2 = null;
b3 = null;
b4 = null;
b5 = null;
printStatus("Back");
}
}
}

(don't think so much about the dk.vajhoej.vms.call.lib stuff -
it does what you think it does)

Arne

On 10/22/2023 1:44 PM, Arne Vajhøj wrote:
> On 10/19/2023 8:55 PM, Jake Hamby (Solid State Jake) wrote:
>> For the record, the default JVM heap size in the current OpenJDK 8
>> x86-64 port is 3.50 GB, at least for a VM with 16 GB RAM:
>
> I believe the default should be 25% of RAM. Which matches your numbers
> reasonable (it could deduct some RAM for some reason).
>
>> $ java -XshowSettings:vm
>> VM settings:
>>      Max. Heap Size (Estimated): 3.50G
>>      Ergonomics Machine Class: server
>>      Using VM: OpenJDK 64-Bit Server VM
>> $ java -version
>> openjdk version "1.8.0_372"
>> OpenJDK Runtime Environment (build 1.8.0_372-b07)
>> OpenJDK 64-Bit Server VM (build 25.372-b07, mixed mode)
>>
>> After running all of the Renaissance JVM benchmarks, which stressed
>> the JVM to its limit, "show proc/acc" showed usage of:
>>
>> Peak working set size: 6634496 pagelets = 3240 MiB
>> Peak virtual size: 10359200 pagelets = 5058 MiB
>>
>> So my previous post about pgflquo needing to be nearly twice as high
>> as the heap size was demonstrated by the accounting data, and the
>> peak working set size was indeed just under the max Java heap size.
> It surprises me, but it looks that way.
>
> My test:
>
> $ javac -cp /vmsjavacallpath/vmscall.jar:/vmsjavacallpath/record.jar
> MemAna.java
> $ java "-Xms64m" "-Xmx768m" -cp
> .:/vmsjavacallpath/vmscall.jar:/vmsjavacallpath/record.jar "MemAna"
> Start               : heap =     5476, wssize =   150592, pgcnt = 95168,
> usedpgfl =   242752
> New 100000 pages    : heap =   102760, wssize =   207712, pgcnt =
> 198256, usedpgfl =   393680
> New 100000 pages    : heap =   203644, wssize =   379072, pgcnt =
> 300288, usedpgfl =   615632
> New 100000 pages    : heap =   304870, wssize =   493312, pgcnt =
> 487280, usedpgfl =   866448
> New 100000 pages    : heap =   406151, wssize =   607552, pgcnt =
> 550800, usedpgfl =  1117248
> New 100000 pages    : heap =   507445, wssize =   778912, pgcnt =
> 551232, usedpgfl =  1368048
> Back                : heap =     7445, wssize =   778912, pgcnt =
> 551232, usedpgfl =  1368048
> New 100000 pages    : heap =   107060, wssize =   778912, pgcnt =
> 551088, usedpgfl =  1293008
> New 100000 pages    : heap =   206702, wssize =   778912, pgcnt =
> 550960, usedpgfl =  1223680
> New 100000 pages    : heap =   306702, wssize =   778912, pgcnt =
> 584352, usedpgfl =  1223680
> New 100000 pages    : heap =   406702, wssize =   836032, pgcnt =
> 646464, usedpgfl =  1223680
> New 100000 pages    : heap =   507446, wssize =   893152, pgcnt =
> 646976, usedpgfl =  1368048
> Back                : heap =     7445, wssize =   893152, pgcnt =
> 647216, usedpgfl =  1368048
> New 100000 pages    : heap =   107060, wssize =   893152, pgcnt =
> 647488, usedpgfl =  1293008
> New 100000 pages    : heap =   206703, wssize =   893152, pgcnt =
> 647360, usedpgfl =  1223680
> New 100000 pages    : heap =   306703, wssize =   893152, pgcnt =
> 647360, usedpgfl =  1223680
> New 100000 pages    : heap =   406714, wssize =   893152, pgcnt =
> 648800, usedpgfl =  1223680
> New 100000 pages    : heap =   507458, wssize =   893152, pgcnt =
> 649136, usedpgfl =  1368064
> Back                : heap =     7457, wssize =   893152, pgcnt =
> 649152, usedpgfl =  1368064

But I can squeeze memory usage down by reducing Xmx, which
force the JVM to GC more agressively:

$ java "-Xms64m" "-Xmx320m" -cp
..:/vmsjavacallpath/vmscall.jar:/vmsjavacallpath/record.jar "MemAna"
Start : heap = 5476, wssize = 150592, pgcnt =
85376, usedpgfl = 243184
New 100000 pages : heap = 104262, wssize = 207712, pgcnt =
178976, usedpgfl = 394112
New 100000 pages : heap = 203642, wssize = 321952, pgcnt =
280496, usedpgfl = 616064
New 100000 pages : heap = 304365, wssize = 493312, pgcnt =
373744, usedpgfl = 769408
New 100000 pages : heap = 404358, wssize = 607552, pgcnt =
477552, usedpgfl = 769408
New 100000 pages : heap = 504354, wssize = 664672, pgcnt =
480928, usedpgfl = 769408
Back : heap = 3168, wssize = 664672, pgcnt =
481088, usedpgfl = 769408
New 100000 pages : heap = 103536, wssize = 664672, pgcnt =
544256, usedpgfl = 754480
New 100000 pages : heap = 203803, wssize = 721792, pgcnt =
544272, usedpgfl = 754480
New 100000 pages : heap = 304041, wssize = 778912, pgcnt =
544288, usedpgfl = 769408
New 100000 pages : heap = 404152, wssize = 778912, pgcnt =
544304, usedpgfl = 769408
New 100000 pages : heap = 504222, wssize = 778912, pgcnt =
544304, usedpgfl = 769408
Back : heap = 3082, wssize = 778912, pgcnt =
544320, usedpgfl = 769408
New 100000 pages : heap = 103463, wssize = 778912, pgcnt =
544736, usedpgfl = 754480
New 100000 pages : heap = 203757, wssize = 778912, pgcnt =
544736, usedpgfl = 754480
New 100000 pages : heap = 304011, wssize = 778912, pgcnt =
544752, usedpgfl = 769408
New 100000 pages : heap = 404144, wssize = 778912, pgcnt =
546176, usedpgfl = 769408
New 100000 pages : heap = 504222, wssize = 778912, pgcnt =
546208, usedpgfl = 769408
Back : heap = 3086, wssize = 778912, pgcnt =
546224, usedpgfl = 769408

So a generous Xmx reduces GC which increase page file quota
usage.

Arne