Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
nativelib regex RE2.Machine mutual exclusion improvements, re2j PR 85…
… & more * This PR ports [re2j](https://github.com/google/re2j/) PR #[85](google/re2j#85) "Don't create Machine while holding this' monitor", dated 2019-02-22, to Scala Native. My thanks and appreciation to the re2j developer @sjamesr for the re2j PR. * Since ScalaNative is currently single threaded, this PR may seem to be not worth the overhead. At the very least, it keeps the scalanative.regex/re2s implementation close to the re2j parent. In the longer run, I do believe that someday, Real Soon Now, a Big Switch will be thrown and not having synchronization issues that could & should have been avoided sprinkled all over the code base will be seen to be a Good Thing. * The port looks slightly different than one would expect from the normal java-to-scala differences. The essence of the re2j PR is maintained but there is a difference in implementation. ScalaNative does not yet implement the ArrayDeque introduced by re2j in its PR. This port retains the ArrayList implementation used by re2j before the PR and by re2s/sn_regex. The ArrayList has worked well for sn_regex. I studied ArrayDeque and it seemed to offer no obvious performance advantages, given that RE2.get() is implemented to remove the last element of the list. * ScalaNative Issue scala-native#1091 describes a bug where monitor methods are not generated when `synchronized` is used with `def`. It reports that the code generated for interior synchronized blocks is correct. There are three uses of `synchronized` in the scalanative.regex package. + This PR naturally changed RE2.get(). + RE2.reset() and RE2.put() were changed and the reason commented. * No unit-tests were added. The re2j PR had no changes associated with testing. Focus testing the behavior on a single threaded ScalaNative would be hard. While it can not be shown that this PR introduced the positive change it describes, it can be shown, to a reasonable degree of certitude, that it did not introduce obvious negative changes, a.k.a. bugs: `test-all` in release-fast mode succeeds with no new performance issues. Documentation: * The standard changelog entry is requested. Testing: * Built and tested ("test-all") in release-fast mode using sbt 1.2.8 on X86_64 only . All tests pass.
- Loading branch information