On Mon, 18 Jan 2021 07:47:30 GMT, Peter Levart wrote:
>> Philippe Marschall has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add unit tests
>>
>> - add unit test for Reader#read(CharBuffer)
>> - add unit test for
Renaming that thing would make sense. It tripped me up too when I was new
to OpenJDK.
..Thomas
On Mon, Jan 18, 2021 at 9:07 PM Claes Redestad
wrote:
> No problem :-)
>
> I've been advocating for renaming the /jdk intermediary into
> something that would make it perfectly obvious to newcomers
Thanks Mandy.
Yes, @CS is a complicated beast.
I also implemented a part of JDK-6824466 for my "proxies should use
hidden classes prototype". (Only for the "constructor for
serialization", as hidden classes can't be mentioned in the constant pool.)
For the @CS method that can be called
> 8259796: timed CompletableFuture.get may swallow InterruptedException
Martin Buchholz has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains one commit:
JDK-8259796
-
Changes:
On Sun, 17 Jan 2021 18:52:04 GMT, Doug Lea wrote:
>> Martin Buchholz has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains one commit:
>>
>> JDK-8259796
>
> Marked as reviewed by dl (Reviewer).
we additionally tweaked timedGet with
ZipFile.Source.initCEN verifies that entry names are encoding into bytes valid
in the entry's encoding. It does so by calling encoding-specific checking
methods, so it also needs to determine which check method to call for each
entry.
By moving the encoding-variant checks into ZipCoder,
On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad wrote:
> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which
> has fast-paths for common encoding) and avoiding a `toCharArray` call on the
> input by refactoring the `normalizeNativePath` code to operate on `String`.
>
This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which
has fast-paths for common encoding) and avoiding a `toCharArray` call on the
input by refactoring the `normalizeNativePath` code to operate on `String`.
This might have a cost on files on Mac that need additional
> Please review this change which fixes the type of the private
> Reference.discovered field. It was Reference, but that's wrong because
> it can be any Reference object.
>
> I've changed it to Reference and let that flow through, updating some
> other variables that were previously somewhat
Hi Johannes,
There has been a couple of the prototypes regarding @CS methods (Alan
did one and I did another) in the context of JDK-6824466. There are lots
of security consideration regarding @CS methods. You are welcome to go
deeper in that area. If you are looking for starter bugs to fix,
No problem :-)
I've been advocating for renaming the /jdk intermediary into
something that would make it perfectly obvious to newcomers that _this
is not it_, but I keep getting shot down. Short name convenient!
/Claes
On 2021-01-18 20:53, Eirik Bjørsnøs wrote:
Alan,
Apologies for wasting
Alan,
Apologies for wasting everyone's time (my own included, although I learned
a lot!)
I found images/jdk, and with that there is no regression.
Back to square one :-)
Thanks,
Eirik.
On Mon, Jan 18, 2021 at 8:35 PM Eirik Bjørsnøs wrote:
>
> Alan,
>
> I have been using "make images" all
On 18/01/2021 19:35, Eirik Bjørsnøs wrote:
Alan,
I have been using "make images" all along. This
produces build/macosx-x86_64-server-release/jdk/modules with unpacked
modules.
build/macosx-x86_64-server-release/jdk is an "exploded image". Think of
it as an intermediate build or step in
> On Jan 18, 2021, at 12:28 PM, Peter Levart wrote:
> If you introduce a private method in Reference:
>
>private void enqueueFromPending() {
>var q = queue;
>if (q != ReferenceQueue.NULL) q.enqueue(this);
>}
>
> ...and use it Reference.processPendingReferences while loop
Alan,
I have been using "make images" all along. This
produces build/macosx-x86_64-server-release/jdk/modules with unpacked
modules.
I'm a bit confused since "make help" seems to indicate that "make jdk"
should create unpacked modules, while "make images" should perhaps not? Or
did I
On 18/01/2021 19:24, Eirik Bjørsnøs wrote:
For good measure, I did a JFR recording which revealed that
ExplodedModuleReader was doing file stat in 263 of 277 native method
samples.
Which lie explains all this, since the 15 I used was not shipped with
exploded jmods..
How do I build OpenJDK
For good measure, I did a JFR recording which revealed that
ExplodedModuleReader was doing file stat in 263 of 277 native method
samples.
Which lie explains all this, since the 15 I used was not shipped with
exploded jmods..
How do I build OpenJDK with packaged modules?
Cheers,
Eirik.
On Mon,
I also measured the actual startup time of Spring Petclinic to assess
real-life impact. Although there is some variance from run to run, it does
seem to regress:
15: Typical startup time 7500 - 7800 ms
17: Typical startup time: 8100 - 8700 ms
Eirik.
On Mon, Jan 18, 2021 at 7:34 PM Eirik
For reference, here's the EnterpriseClassloader benchmark I made.
It assumes you have the jar files from Spring Petclinic in BOOT-INF/lib
(but any large collection of jars should work).
public class ZIPBenchmark {
public static void main(String[] args) {
final File libDir = new
Ensure make files look on the include path or in PHASE_MAKEDIRS for
customizations.
Change also adds a tidy-up that improves readability.
-
Commit messages:
- 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk
Changes:
Hello,
I've been looking into ZipFile again with the aim to speed up typical
enterprise classloading / resource lookups.
To test the performance impact of my changes, I made a benchmark which
creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar
files in Spring Petclinic (89
On Mon, 18 Jan 2021 09:26:07 GMT, Claes Redestad wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>>
On Sat, 26 Dec 2020 03:25:51 GMT, Kim Barrett wrote:
> Please review this change which fixes the type of the private
> Reference.discovered field. It was Reference, but that's wrong because
> it can be any Reference object.
>
> I've changed it to Reference and let that flow through, updating
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
>
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
>
> Please review this change which fixes the type of the private
> Reference.discovered field. It was Reference, but that's wrong because
> it can be any Reference object.
>
> I've changed it to Reference and let that flow through, updating some
> other variables that were previously somewhat
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman When I moved the charset templates, I found
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually* used by
> make for the whole build.)
>
> These data files should move
Hi all,
For this reproducer:
import jdk.incubator.vector.ByteVector;
import jdk.incubator.vector.VectorSpecies;
public class Test {
static final VectorSpecies SPECIES_128 = ByteVector.SPECIES_128;
static byte[] a = new byte[8];
static byte[] b = new byte[8];
public static void
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in
On 2021-01-15 19:27, mark.reinh...@oracle.com wrote:
Feature JEPs are living documents until such time as they are delivered.
In this case it would not be appropriate to update JEP 201, which is as
much about the transition from the old source-code layout as it is about
the new layout as of
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in
Change `MethodHandles.byteArrayViewVarHandle` to throw
`ArrayIndexOutOfBoundsException` rather than the more generic
`IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk
for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs.
CSR:
> 8252412: [macos11] system dynamic libraries removed from filesystem
Martin Buchholz has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contains one
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
On Sat, 9 Jan 2021 23:06:22 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
36 matches
Mail list logo
