On 2020-04-15 00:34, Ioi Lam wrote:
I am a little worried adding extra overhead unconditionally into the JAR
reader that people may not need/want.
Maybe we should take a step back and see why there are so many misses?
Is it because you have a long classpath with many JARs on it, and you
On 4/13/20 12:26 PM, Eirik Bjørsnøs wrote:
Hi,
While working on improvements to JarFile.getVersionedEntry, it occurred to
me that the missing lookups we are removing there may be just one example
of a more general issue.
To get a better understanding of how ZipFile.getEntry is used, I added
Hi Mark,
On 15/04/2020 3:09 am, Mark Kralj-Taylor wrote:
David, Daniel,
What is the oldest (lowest) version of Linux and glibc for openjdk 15?
I'm not clear on that.
The availability of clock_gettime(CLOCK_REALTIME) on the oldest
Linux/glibc supported by openjdk 15 is likely to be the
Hi,
Noticed in the OpenJDK sources that String::stripIndent,
String::translateEscapes, String::formatted were annotated with
@jdk.internal.PreviewFeature until the very recent time [1].
Are there any plans to move this annotation out of “jdk” namespace to “java” or
“javax” namespace?
This
David, Daniel,
What is the oldest (lowest) version of Linux and glibc for openjdk 15?
The availability of clock_gettime(CLOCK_REALTIME) on the oldest
Linux/glibc supported by openjdk 15 is likely to be the deciding
factor on if Hotspot Linux code can call
clock_gettime(CLOCK_REALTIME).
Looks good to me (not familiar with all the code areas.
Minor suggestion:
MethodHandles.java
1811 * ASCII periods. For the instance of {@link java.lang.Class}
representing {@code C}:
1812 *
1813 * {@link Class#getName()} returns the string {@code GN + "/"
+ },
On 4/14/20 2:42 PM, Paul Sandoz wrote:
On Apr 14, 2020, at 11:22 AM, Vicente Romero wrote:
Hi Paul,
On 4/14/20 2:05 PM, Paul Sandoz wrote:
Hi Vicente,
Looks ok from the changes required to integrate into the JDK.
Maybe the @SuppressWarnings warning annotations could be upstreamed?
do
> On Apr 14, 2020, at 11:22 AM, Vicente Romero
> wrote:
>
> Hi Paul,
>
> On 4/14/20 2:05 PM, Paul Sandoz wrote:
>> Hi Vicente,
>>
>> Looks ok from the changes required to integrate into the JDK.
>>
>> Maybe the @SuppressWarnings warning annotations could be upstreamed?
>
> do you mean to
Hi Paul,
On 4/14/20 2:05 PM, Paul Sandoz wrote:
Hi Vicente,
Looks ok from the changes required to integrate into the JDK.
Maybe the @SuppressWarnings warning annotations could be upstreamed?
do you mean to ask ASM team to include them? Sorry that I wasn't more
specific, the warnings come
Hi Vicente,
Looks ok from the changes required to integrate into the JDK.
Maybe the @SuppressWarnings warning annotations could be upstreamed?
Paul.
> On Apr 13, 2020, at 8:05 AM, Vicente Romero wrote:
>
> Hi all,
>
> Please review this patch that updates the ASM version to appear in JDK15
* Mark Kralj-Taylor:
> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
> should be supported if the clock_gettime() API exists. But other clock
> sources are not mandatory.
Really old glibc emulates clock_gettime (CLOCK_REALTIME) using
gettimeofday, yes.
clock_gettime was
Daniel,
Yes System.currentTimeMillis() and Clock.systemUTC() must be
consistent, so should use the same OS time source (as shown by ).
The patch to os_linux.cpp ensures this by calling the same Linux API:
clock_gettime(CLOCK_REALTIME) for both, from:
- os::javaTimeMillis() that backs
Hi Naoto,
I agree, see attached patch.
Regards,
Philipp
On Thu, 2020-03-26 at 14:14 -0700, naoto.s...@oracle.com wrote:
> Hi Philipp,
>
> I looked at the patch, and it looks good to me. As to the test case,
> since it is measuring the performance, I would make it in a JMH test.
> Maybe you
Hi David,
Thanks for the heads up! A CSR for this patch was created here:
https://bugs.openjdk.java.net/browse/JDK-8241667
It was moved to 'provisional' today, but still requires one or more
engineer reviews.
Could someone here review the CSR?
Thanks,
Jorn
On 18/03/2020 22:59, David
On Tue, Apr 14, 2020 at 2:06 PM Eirik Bjørsnøs wrote:
> The remaining 33% should be explained by the bloom filter providing a
> faster negative lookup than the hash table.
>
This made me wonder if a hash map is the optimal data structure for this
kind of read-only lookups. There's good amount
Hi,
On 11/04/2020 00:53, David Holmes wrote:
Update:
It's a holiday weekend so I can't dig into this right now but we tried
using a high-precision clock source for systemUTC() in the past but it
didn't work because systemUTC() and currentTimeMillis() have to use
the same time base, and
On 2020-04-14 14:06, Eirik Bjørsnøs wrote:
I wonder if the overhead you remove here is mainly avoiding the need to
call byte[] bname = zc.getBytes(name); during lookup.
If I got my numbers right, 67% of the saved time was due to less
executions of this method.
The remaining 33%
>
> I wonder if the overhead you remove here is mainly avoiding the need to
> call byte[] bname = zc.getBytes(name); during lookup.
>
If I got my numbers right, 67% of the saved time was due to less executions
of this method.
The remaining 33% should be explained by the bloom filter providing a
Hi Eirik,
interesting idea and results.
I wonder if the overhead you remove here is mainly avoiding the need to
call byte[] bname = zc.getBytes(name); during lookup.
If we refactored ZipCoder to have a zc.getHash(name) method and
getEntryPos to decode to a byte[] only lazily, we ought to be
Here's a patch implementing the Bloom filter idea for JarFile.getEntry().
The patch yields a 63% time saving in ZipFile.getEntry() calls during
Spring Petclinic startup, reducing total application startup time by ~5%.
(Hits are 7% slower, misses 65% faster)
The current patch decodes the name to
On Tue, Apr 14, 2020 at 10:15 AM Alan Bateman
wrote:
Would it be possible to send an updated webrev with the patch that is
> proposed for jdk/jdk?
My understanding is that Claes may initiate a formal review once my OCA is
processed and he's done some testing.
> One thing that I'm concerned
Would it be possible to send an updated webrev with the patch that is
proposed for jdk/jdk? One thing that I'm concerned about is that
META-INF/* is a JAR file concepts and I'd prefer not build up further
shared secrets that operate on ZipFile (should be consistent JarFile and
JarEntry when
Hello,
I was wondering what the motivation was behind exposing the
getGenericSignature method in RecordComponent. This method also exists in
the Method and Field classes but is private there. If there is an argument
to expose the method in RecordComponent, wouldn't it make sense to also
expose it
23 matches
Mail list logo
