Integrated: 8316461: Fix: make test outputs TEST SUCCESS after unsuccessful exit

2023-09-20 Thread Leo Korinth
On Tue, 19 Sep 2023 14:44:26 GMT, Leo Korinth wrote: > `make test` outputs `TEST SUCCESS` after unsuccessful exit of JVM. One > example is bad VM flags. > > I now have a reproducer for something that has puzzled me before (and most of > my co-workers I think): > > /

Re: RFR: 8316461: Fix: make test outputs TEST SUCCESS after unsuccessful exit [v2]

2023-09-20 Thread Leo Korinth
On Wed, 20 Sep 2023 07:49:20 GMT, Leo Korinth wrote: >> `make test` outputs `TEST SUCCESS` after unsuccessful exit of JVM. One >> example is bad VM flags. >> >> I now have a reproducer for something that has puzzled me before (and most >> of my co-workers I thi

Re: RFR: 8316461: Fix: make test outputs TEST SUCCESS after unsuccessful exit [v2]

2023-09-20 Thread Leo Korinth
ailure or success without a > mutating directory, but It would be good if I could get that confirmed > (because I have a hard time understanding the make files). Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: clean-workdir-$1

Re: RFR: 8316461: Fix: make test outputs TEST SUCCESS after unsuccessful exit

2023-09-20 Thread Leo Korinth
On Tue, 19 Sep 2023 14:44:26 GMT, Leo Korinth wrote: > `make test` outputs `TEST SUCCESS` after unsuccessful exit of JVM. One > example is bad VM flags. > > I now have a reproducer for something that has puzzled me before (and most of > my co-workers I think): > > /

RFR: 8316461: Fix: make test outputs TEST SUCCESS after unsuccessful exit

2023-09-19 Thread Leo Korinth
`make test` outputs `TEST SUCCESS` after unsuccessful exit of JVM. One example is bad VM flags. I now have a reproducer for something that has puzzled me before (and most of my co-workers I think): // first test uses -XX:+UseG1GC second and third uses -XX:+UseG1GCC (sic) `make clean run-test

Withdrawn: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Leo Korinth
On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the > files are "dirty" to begin with. This fix will make more files "clean&

Re: RFR: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Leo Korinth
On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the > files are "dirty" to begin with. This fix will make more files "clean&

Re: RFR: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Leo Korinth
On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore wrote: > You could fix your emacs functions. It is a *very nice* feature of global-whitespace-cleanup-mode - PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347

Re: RFR: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Leo Korinth
On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes wrote: > Neither the PR diffs nor the webrev make it easy to see exactly what is being > changed here. It appeared to me that the last empty line of each file was > being deleted, leaving no newline at the end. My changes look like this in the

Re: RFR: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Leo Korinth
On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore wrote: > Why do we care about this? I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing

Re: RFR: 8311043: Remove trailing blank lines in source files

2023-06-29 Thread Leo Korinth
On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes wrote: > This seems to run contrary to the requirement that files end in a newline, > which git will complain about if the newline is missing. > > It also seems far too large and disruptive. Do you still think it is too disruptive after Erik's

RFR: 8311043: Remove trailing blank lines in source files

2023-06-28 Thread Leo Korinth
Remove trailing "blank" lines in source files. I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling

Integrated: 8309468: Remove jvmti Allocate locker test case

2023-06-13 Thread Leo Korinth
On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. > One of the test is named jvmti locker. In that test, JNI code is doing a loop > of ` jvmti->Allocate()` followed `sleep()` followed by a > `jv

Re: RFR: 8309468: Remove jvmti Allocate locker test case

2023-06-13 Thread Leo Korinth
On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. > One of the test is named jvmti locker. In that test, JNI code is doing a loop > of ` jvmti->Allocate()` followed `sleep()` followed by a > `jv

RFR: 8309468: Remove jvmti Allocate locker test case

2023-06-12 Thread Leo Korinth
There is a bunch of tests that are used to test critical section/gc locker. One of the test is named jvmti locker. In that test, JNI code is doing a loop of ` jvmti->Allocate()` followed `sleep()` followed by a `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on jvmti

Integrated: 8309048: Remove malloc locker test case

2023-05-31 Thread Leo Korinth
On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. > One of the test is named malloc. In that test, JNI code is doing a loop of > `malloc()` followed `sleep()` followed by a `free()`. There is no

Re: RFR: 8309048: Remove malloc locker test case

2023-05-31 Thread Leo Korinth
On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. > One of the test is named malloc. In that test, JNI code is doing a loop of > `malloc()` followed `sleep()` followed by a `free()`. There is no

RFR: 8309048: Remove malloc locker test case

2023-05-29 Thread Leo Korinth
There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time,

Re: RFR: 8296926: Sort include lines of files in the include/ directory [v4]

2022-11-16 Thread Leo Korinth
On Wed, 16 Nov 2022 11:02:19 GMT, Stefan Karlsson wrote: >> One of the more prevalent issues is that files in src/hotspot/share/include >> are not properly sorted. There has been some discussion that that was done >> on purpose, but it just adds another exception to the include rules that >>

Integrated: 8287828: Fix so that one can select jtreg test case by ID from make

2022-08-22 Thread Leo Korinth
On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth wrote: > One can select a testcase by ID when running a jtreg test case directly from > jtreg (using the testcase.java#testID syntax). However, this has not been > possible to do when launching jtreg indirectly from make. > > Th

Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v6]

2022-06-28 Thread Leo Korinth
On Mon, 27 Jun 2022 14:27:36 GMT, Leo Korinth wrote: >> One can select a testcase by ID when running a jtreg test case directly from >> jtreg (using the testcase.java#testID syntax). However, this has not been >> possible to do when launching jtreg indirectly from mak

Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v6]

2022-06-27 Thread Leo Korinth
those instead. If they do not exist, they might be useful > elsewhere and maybe should be placed in a common make file instead of the > RunTests.gmk file. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: remove one unness