Hi Igor,
thank you for taking the time to answer my grumblings.
Yes, comparison with jtreg is a bit crooked - it is not needed to get a
valid build. But jtreg is also maintained in the official OpenJDK
repositories; I can clone codetools/jtreg and have the correct version.
With gtests, I have to
Hi Thomas,
I regret that this patch made you unhappier. I fully agree that all hotspot
developers are to always build *and* run gtest tests, yet not all people who
work on OpenJDK project are hotspot developers.
I also believe that all OpenJDK developers are to run tests related to the area
th
+1
Thanks,
David
On 29/05/2020 7:53 am, Erik Joelsson wrote:
Build changes look fine.
/Erik
On 2020-05-28 14:51, Joe Darcy wrote:
Hello,
The start of JDK 16 is right around the corner with JDK 15 forking off
from jdk/jdk at ramp down 1 [1].
Please review the usual build-related portions
Build changes look fine.
/Erik
On 2020-05-28 14:51, Joe Darcy wrote:
Hello,
The start of JDK 16 is right around the corner with JDK 15 forking off
from jdk/jdk at ramp down 1 [1].
Please review the usual build-related portions of
http://cr.openjdk.java.net/~darcy/8235496.4/
The build
Hello,
The start of JDK 16 is right around the corner with JDK 15 forking off
from jdk/jdk at ramp down 1 [1].
Please review the usual build-related portions of
http://cr.openjdk.java.net/~darcy/8235496.4/
The build updates were as expected; the symbol information for JDK 15
was extract
On 2020-05-28 13:51, Erik Gahlin wrote:
Hello Erik,
On 28 May 2020, at 19:47, Erik Joelsson wrote:
Hello Erik,
I noticed that you added an import for java.util.HashSet, but it doesn't seem
to be used.
Fixed.
You also replaced the only use of HashMap with LinkedHashMap, which we like as
Hello Erik,
> On 28 May 2020, at 19:47, Erik Joelsson wrote:
>
> Hello Erik,
>
> I noticed that you added an import for java.util.HashSet, but it doesn't seem
> to be used.
Fixed.
> You also replaced the only use of HashMap with LinkedHashMap, which we like
> as it gives a predictable iter
Hi Erik,
Looks good, thanks for cleaning this up.
Markus
-Original Message-
From: Erik Gahlin
Sent: den 28 maj 2020 19:38
To: j >> hotspot-jfr-...@openjdk.java.net
Cc: build-dev@openjdk.java.net
Subject: RFR: 8216303: JFR: Simplify generated files
Hi,
Could I have a review of a fix t
Hello Erik,
I noticed that you added an import for java.util.HashSet, but it doesn't
seem to be used. You also replaced the only use of HashMap with
LinkedHashMap, which we like as it gives a predictable iteration order,
but forgot to remove the import.
Do you know if the generated files are
Hi,
Could I have a review of a fix that removes legacy in the generated JFR event
files, in particular hard coded numbers for type / event IDs. Event IDs are now
numbered from zero, which has the benefit that most of them can be represented
as a single byte instead of two. This will reduce the
Looks good to me.
-- Jon
On 5/18/20 9:36 AM, Jan Lahoda wrote:
I apologize, I used a wrong patch for the "data" webrev. The "class
name java/util/jar/Attributes$Name" entry in java.base-7.sym.txt is
first adding field descriptions, and then removing the old ones:
---
class name java/util/jar
Hi,
I know the boat has sailed, I missed this one. But I am a bit unhappy about
this.
I always build with gtests; I think it makes no sense to not build with
gtest. Even if you do not want to run the gtests (and it makes sense to
always do since its a good first-base validity test), hotspot devel
12 matches
Mail list logo
