Good idea. Will do.
Best Regards
Adam Farley
IBM Runtimes
Alan Bateman wrote on 26/08/2020 11:45:26:
> From: Alan Bateman
> To: Adam Farley8 , core-libs-dev d...@openjdk.java.net>
> Date: 26/08/2020 11:45
> Subject: [EXTERNAL] Re: RFR: JDK-8252113: Move jfr man page i
Hi All,
Should jfr.1 be moved from java.base to the jdk.jfr module source
directory, as indicated here?
Webrev: http://cr.openjdk.java.net/~afarley/8252113/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8252113
It seems to me that it should, as man pages should be with their code (as
a
o
sponsor and merge, please?
Best Regards
Adam Farley
IBM Runtimes
"Thomas Stüfe" wrote on 21/04/2020 18:29:23:
> From: "Thomas Stüfe"
> To: Adam Farley8
> Cc: core-libs-dev , Roger Riggs
>
> Date: 21/04/2020 18:29
> Subject: [EXTERNAL] Re: RFR: 82393
Thanks for your feedback. :)
Best Regards
Adam Farley
IBM Runtimes
"Thomas Stüfe" wrote on 03/03/2020 10:52:10:
> From: "Thomas Stüfe"
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 03/03/2020 10:52
> Subject: [EXTERNAL] Re: RFR: 8239365: ProcessBu
as it passes when it should pass, and fails only when it should
fail, clarity is a "would be nice", but ultimately a secondary priority.
Thanks for your feedback. :)
Best Regards
Adam Farley
IBM Runtimes
"Thomas Stüfe" wrote on 03/03/2020 10:52:10:
> From: "Thomas
Hi All,
Reviews and sponsor requested for a small test change.
Short version: When an AIX machine has the file set "bos.msg.en_US.rte",
the error messages are not in a form that the test expects, causing
failure.
The simplest option appears to be adding the second potential form of the
messag
Hi All,
Reviews and sponsor requested for a small test change.
Parts of the test appear to be pattern-matching on error messages from
catalogues on the system.
When an AIX machine has the file set "bos.msg.en_US.rte", the messages are
different for the same codes.
E.g. for Error code 13 (in t
n 06/01/2020 23:36:14:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 06/01/2020 23:38
> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
> for Specific Classes
>
> Hi Adam,
>
> Thanks for the examples. I was hoping for some c
Bump :)
Hi Mandy,
Sorry for the delay in responding.
Mandy Chung wrote on 29/10/2019 19:30:55:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 29/10/2019 19:31
> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
> for Specific Cl
Thanks Paul. :)
Best Regards
Adam Farley
IBM Runtimes
"Hohensee, Paul" wrote on 10/12/2019 20:16:31:
> From: "Hohensee, Paul"
> To: Severin Gehwolf , Adam Farley8
> , Java Core Libs
> Cc: jdk8u-dev
> Date: 10/12/2019 20:16
> Subject: [EXTERNAL]
Hi Mandy,
Sorry for the delay in responding.
Mandy Chung wrote on 29/10/2019 19:30:55:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 29/10/2019 19:31
> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
> for Specific Classes
>
&g
net/~afarley/8232773/webrev/
Best Regards
Adam Farley
IBM Runtimes
From: David Holmes
To: Martin Buchholz
Cc: Ioi Lam , core-libs-dev
, Adam Farley8
Date: 24/10/2019 05:22
Subject:[EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
for Specific Classes
Hi All,
I'm asking for reviewers, sponsors, and opinions on the changes proposed
below.
Right now, there are four files in OpenJDK 8 that have a GPL V2 License,
with no Classpath Exception.
Based on the conversation so far, here's a summary of the proposed
actions:
1) Remove this file, along
he "loading the wrong version
of a class" problem, but does not seem to give us
information in the case of class loading failure.
Also, thanks for moving the bug to the correct component. :)
Best Regards
Adam Farley
IBM Runtimes
David Holmes wrote on 22/10/2019 14:12:55:
>
Hi Alan,
Thanks for the quick response.
Stewart, if you have a moment, could you please advise on the section with
the @Stewart tag?
Alan Bateman wrote on 22/10/2019 12:36:26:
> From: Alan Bateman
...
> This looks very messy and I don't think is in any state to be reviewed.
I'm sorry to he
Hey All,
This one goes out to anyone who's struggled to figure out
why OpenJDK isn't loading their class.
The requirement is for OpenJDK to give more detailed
information while loading user-specified classes (e.g. the
one OpenJDK is failing to load). Some debug information is
available while
_hdr_flags/fix_empty_sec_hdr_flags.c
Best Regards
Adam Farley
IBM Runtimes
Alan Bateman wrote on 07/10/2019 13:57:53:
> From: Alan Bateman
> To: Adam Farley8 , Joe Darcy
> , sergey.bylok...@oracle.com,
> lana.ste...@oracle.com, magnus.ihse.bur...@oracle.com
> Cc: Java Core Libs , Floria
nd up in a build, so some may only need to be
considered as source.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 04/10/2019 17:28:59:
> From: Joe Darcy
>
Hi Joe,
That sounds reasonable.
Would you, or another Oracle employee, mind sponsoring the change?
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 03/10/2019 23:30:14:
> From: Joe Darcy
> To: Florian Weimer , Adam Farley8
> Cc: jdk-updates-...@openjdk.java.net, Java
BM Runtimes
Florian Weimer wrote on 03/10/2019 21:42:52:
> From: Florian Weimer
> To: Adam Farley8
> Cc: "Java Core Libs" , jdk-updates-
> d...@openjdk.java.net
> Date: 03/10/2019 21:43
> Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
>
Hey all,
Four GPLv2 files in 8u seem to be missing the classpath exception from the
copyright section.
Requesting reviews and a sponsor.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
Best Regards
Adam Farley
IBM Runtimes
U
Good job. :)
On to the next bug! Hehe.
Best Regards
Adam Farley
IBM Runtimes
Martin Buchholz wrote on 07/05/2019 19:46:26:
> From: Martin Buchholz
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 07/05/2019 19:46
> Subject: Re: RFR: JDK-8222930: ConcurrentSkipLi
Thanks Martin. :)
Best Regards
Adam Farley
IBM Runtimes
Martin Buchholz wrote on 02/05/2019 15:14:32:
> From: Martin Buchholz
> To: Adam Farley8
> Cc: David Holmes , Chris Hegarty
> , core-libs-dev d...@openjdk.java.net>, Doug Lea , Jonathan Gibbons
>
> Date: 02/05
es
> To: Martin Buchholz , core-libs-dev d...@openjdk.java.net>, Doug Lea , Chris Hegarty
> , Adam Farley8 ,
> Jonathan Gibbons
> Date: 30/04/2019 08:52
> Subject: Re: RFR: jsr166 integration 2019-05
>
> Hi Martin,
>
> On 30/04/2019 4:00 am, Martin Buchholz wrote:
&g
Hi All,
Reviews and feedback requested for the fix.
http://cr.openjdk.java.net/~afarley/8222930.1/jdk13/webrev
Martin: Thanks for the testcase. I've replaced the old test in the webrev
with your generalized one. :)
Best Regards
Adam Farley
IBM Runtimes
Adam Farley8/UK/IBM wrote on
Hi Stuart,
Whoops, typo. Thanks for catching that.
Ditto for Martin, who has modified the bug. :)
Best Regards
Adam Farley
IBM Runtimes
Stuart Marks wrote on 24/04/2019 17:59:17:
> From: Stuart Marks
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 24/04/2019 17:59
> S
Hi All,
ConcurrentSkipListMapTest.clone() produces a clone that shares the array
size variable of the original, and then doubles it.
So both arrays, original and clone, tell the user that each is twice as
big as it actually is.
The proposed fix is to simply set the clone's array size variable
t; To: Adam Farley8 , Joe Darcy
> Cc: core-libs-dev
> Date: 26/03/2019 03:51
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
>
> On 3/25/19 11:36 AM, Adam Farley8 wrote:
> Addendum: URL for new
Addendum: URL for new webrev:
http://cr.openjdk.java.net/~afarley/8216558.1/webrev/
Adam Farley8/UK/IBM wrote on 25/03/2019 18:04:05:
> From: Adam Farley8/UK/IBM
> To: Joe Darcy
> Cc: core-libs-dev , Mandy Chung
>
> Date: 25/03/2019 18:04
> Subject: Re
a.net/pipermail/core-libs-dev/2019-March/059191.html
Also, I have read the guide (finally), and I see the tests should have a
bug tag. I'll add that now, in a versioned webrev.
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 25/03/2019 17:34:42:
> From: Joe Darcy
>
Hiya Joe,
Response below,
Joe Darcy wrote on 22/03/2019 17:05:33:
> From: Joe Darcy
> To: Adam Farley8
> Cc: core-libs-dev , Mandy Chung
>
> Date: 22/03/2019 17:06
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessExcep
Hiya Joe,
Responses below.
Joe Darcy wrote on 22/03/2019 17:06:38:
> From: Joe Darcy
> To: Mandy Chung , Adam Farley8
>
> Cc: core-libs-dev
> Date: 22/03/2019 17:07
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessExcep
Hi Mandy,
Mandy Chung wrote on 22/03/2019 16:56:12:
> From: Mandy Chung
> To: Joe Darcy , Adam Farley8
> Cc: core-libs-dev
> Date: 22/03/2019 16:58
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
cy
> To: Adam Farley8 , Mandy Chung
>
> Cc: core-libs-dev
> Date: 22/03/2019 15:42
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> A quick comment below...
>
> On 3/22/2019 4:3
Hi Mandy,
Answers below. :)
Mandy Chung wrote on 22/03/2019 00:35:00:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 22/03/2019 00:35
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for fina
against a non-patched java, so I think we're ok.
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 20/03/2019 05:08:37:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 20/03/2019 05:10
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectS
; To: Mandy Chung , Adam Farley8
>
> Cc: core-libs-dev
> Date: 12/03/2019 03:34
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
>
> On 3/11/2019 3:49 PM, Mandy Chung wrote:
> >
> >
>
Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 07/03/2019 23:19
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
>
>
> On 3/7/19 9:44 AM, Adam Farley8 wrote:
> > Hi Mandy,
>
From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 07/03/2019 15:40
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> Hi Adam,
>
> On 3/6/19 8:28 AM, Adam Farley8 wrote:
> >
) nobody is meant to be changing
final fields anyway.
Open for review.
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 01/03/2019 17:50:49:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 01/03/2019 17:50
> Subject: Re: RFR: JDK-8216558: Lookup.
ley
IBM Runtimes
Mandy Chung wrote on 21/02/2019 17:37:54:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 21/02/2019 17:41
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
&g
+ }
+
@Test
public void testFindSetter() throws Throwable {
CodeCacheOverflowProcessor.runMHTest(this::testFindSetter0);
}
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 31/01/2019 18:58:25:
> From:
d is not a suitable test?
Please advise.
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 30/01/2019 18:22:40:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 30/01/2019 18:22
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter
wrote on 23/01/2019 19:18:09:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 23/01/2019 19:17
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> Hi Adam,
>
> On 1/23/1
.unreflectSetter}.
Perhaps he means it will still fail, but for the reasons we've discussed
rather than anything connected to access control?
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 16/01/2019 23:52:03:
> From: Mandy Chung
> To: Adam Farley8
> Cc: co
Hi All,
Some comments below.
> A CSR request will need to be filed.
>
> >>>
> >>> Of course, as this is a spec change.
> >>
> >> I'm unclear what spec is actually to be changed here and in what way?
As am I.
> >
> > I expect Adam will send a revised webrev to include the proposed s
l
field, I think we can agree that unreflectSetter should fail to create a
setter MethodHandle for this same field.
Best Regards
Adam Farley
IBM Runtimes
Remi Forax wrote on 11/01/2019 13:11:48:
> From: Remi Forax
> To: David Holmes
> Cc: Adam Farley8 , core-libs-dev d...@openjdk
Hi All,
I posit that you shouldn't be able to change the contents of a a final
field.
However, if you use Field.setAccessible(true) before calling
Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows
you to set the (reflected) value of a static final field.
This seems w
Update: The revised webrev can be found here:
http://cr.openjdk.java.net/~afarley/8215217/webrev/
It can also be found in the zip attached to the bug.
Best Regards
Adam Farley
IBM Runtimes
Adam Farley8/UK/IBM wrote on 13/12/2018 11:49:12:
> From: Adam Farley8/UK/IBM
> To: Stuart
Hi Stuart,
A good compromise. Well referenced.
Yes, could you sponsor this change?
Thanks,
- Adam
Stuart Marks wrote on 12/12/2018 00:38:32:
...
>
>
> # HG changeset patch
> # User afarley
> # Date 1544574289 28800
> # Tue Dec 11 16:24:49 2018 -0800
> # Node ID 0c40c78b6d139eb05b0718d0
provide them as a zip file.
>
> Thank you and best regards,
> Volker
> On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8
wrote:
> >
> > Hey All,
> >
> > I've spotted 12 instances of swear words in OpenJDK source comments,
and
>
Alan Bateman wrote on 11/12/2018 15:32:31:
> From: Alan Bateman
> To: Adam Farley8 , core-libs-dev d...@openjdk.java.net>
> Date: 11/12/2018 15:33
> Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words
>
> On 11/12/2018 15:03, Adam Farley8 wrote:
>
Hey All,
I've spotted 12 instances of swear words in OpenJDK source comments, and
it seems appropriate to remove them.
Bug: https://bugs.openjdk.java.net/browse/JDK-8215217
I've created a webrev and attached to the bug.
Also, I've mentioned in the bug that there are additional swears in more
it's easier to link the change to the error. Also, it's shorter.
My 2 cents. Volker, Ichiroh?
Best Regards
Adam Farley
IBM Runtimes
"Ichiroh Takiguchi" wrote on 27/11/2018
12:36:41:
> From: "Ichiroh Takiguchi"
> To: "Volker Simonis"
> Cc: Ad
Did you saw the same problems
> like Adam when compiling "NativeImageBuffer.cpp"?
>
> - If yes, did you fix them by excluding the inclusion of
> "osSupport.hpp" ? That would be strange, because it doesn't seem to
> related to the problems reported until n
llows us to build on versions of xlC other than 12.1.
I propose we call that "Plan B".
Best Regards
Adam Farley
IBM Runtimes
Adam Farley8/UK/IBM wrote on 26/11/2018 13:16:18:
> From: Adam Farley8/UK/IBM
> To: Volker Simonis
> Cc: Java Core Libs , "Stuefe,
> T
?
Best Regards
Adam Farley
IBM Runtimes
Volker Simonis wrote on 22/11/2018 14:25:04:
> From: Volker Simonis
> To: adam.far...@uk.ibm.com
> Cc: Java Core Libs , "Stuefe,
> Thomas"
> Date: 22/11/2018 14:25
> Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX whil
t: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> using the xlc 13.1 compiler
>
> On Wed, Nov 21, 2018 at 1:46 PM Adam Farley8
wrote:
> >
> > Hi Volker,
> >
> > The NativeImageBuffer.cpp changes are best explained by the full text
of
> > the re
iler
>
> On Wed, Nov 21, 2018 at 1:46 PM Adam Farley8
wrote:
> >
> > Hi Volker,
> >
> > The NativeImageBuffer.cpp changes are best explained by the full text
of
> > the referenced GitHub Pull Request, copied here for simplicity:
> >
> > ---
ibs
> Date: 20/11/2018 17:59
> Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> using the xlc 13.1 compiler
>
> On Tue, Nov 20, 2018 at 6:15 PM Thomas Stüfe
wrote:
> >
> > On Tue, Nov 20, 2018 at 6:12 PM Adam Farley8
wrote:
> > >
> >
mas Stüfe" wrote on 20/11/2018 16:44:07:
> From: "Thomas Stüfe"
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 20/11/2018 16:48
> Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> using the xlc 13.1 compiler
>
> Hi Adam,
>
>
visibility("default")))
#else
#define JNIEXPORT
------
Best Regards
Adam Farley
IBM Runtimes
"Thomas Stüfe" wrote on 19/11/2018 18:11:34:
> From: "Thomas Stüfe"
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 19/11/20
Hi All
Both the problem and the solution appear straight-forward enough.
Details included in the bug description.
Thoughts and opinions welcome.
Best Regards
Adam Farley
IBM Runtimes
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
7415
Hi Mandy,
The extra space is fine.
In hindsight, you could probably rename "loaderone" to just "loader" too.
Thanks for helping with this. :)
Best Regards
Adam Farley
OpenJDK Team
Runtimes
IBM
mandy chung wrote on 16/08/2018 18:57:01:
> From: mandy chung
&
chung wrote on 15/08/2018 17:49:51:
> From: mandy chung
> To: Adam Farley8 , Hans Boehm
> Cc: core-libs-dev ,
i18n-...@openjdk.java.net
> Date: 15/08/2018 17:50
> Subject: Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix
included)
>
> Hi Adam,
>
> Thi
m>> wrote:
> >
> > Hi Adam,
> >
> > Have you tried Peter's suggestion if an empty static method taking
an
> > Object parameter? Does it work for you?
> >
> > Your proposed approach seems fine and I would suggest to put the
>
m>> wrote:
> >
> > Hi Adam,
> >
> > Have you tried Peter's suggestion if an empty static method taking
an
> > Object parameter? Does it work for you?
> >
> > Your proposed approach seems fine and I would suggest to put the
>
-- Bump --
Hi Folks,
> Zhengyu Gu wrote on 06/06/2018 01:58:18:
> From: Zhengyu Gu
> To: "Thomas Stüfe" , Adam Farley8
>
> Cc: "hotspot-...@openjdk.java.net developers" d...@openjdk.java.net>, core-libs-dev
> Date: 06/06/2018 01:58
> Subject:
Hi All,
This bug could be fixed by comparing the Class Loader with a blank
static volatile Object (defined outside the method scope) at the
end of the getBundleImpl class.
E.g.
-
+1322
/**
* volatile reference object to guard the ClassLoader obj
Hi Folks,
> Zhengyu Gu wrote on 06/06/2018 01:58:18:
> From: Zhengyu Gu
> To: "Thomas Stüfe" , Adam Farley8
>
> Cc: "hotspot-...@openjdk.java.net developers" d...@openjdk.java.net>, core-libs-dev
> Date: 06/06/2018 01:58
> Subject: Re: RFR Bug-pe
> Alan Bateman wrote on 16/07/2018 15:00:16:
> From: Alan Bateman
> To: Peter Levart , Adam Farley8
> , core-libs-dev
> Date: 16/07/2018 14:59
> Subject: Re: RFR (Unraised): JDK8 ResourceBundle vulnerable to GC
>
> On 16/07/2018 14:12, Peter Levart wrote:
> >
Hi All,
-- Summary:
When calling "ResourceBundle.getBundle(String, Locale, ClassLoader)" on
JDK8, the ClassLoader can get GC'd before we're finished with it.
This can result in us getting the wrong result back, like if we asked for
"Stuff" with the locale "fr, CA" and got back "Stuff_fr.class
Hi All,
Native memory allocation for DBBs is tracked in java.nio.Bits, but that
only includes what the user thinks they are allocating.
When the VM adds extra memory to the allocation amount this extra bit is
not represented in the Bits total. A cursory glance
shows, minimum, that we round th
ation
failed";
> >> Â }
> >>
> >> Thanks,
> >>
> >> Brian
> >>
> >> On May 21, 2018, at 9:50 AM, Brian Burkhalter
> >> wrote:
> >>
> >>> Hi Adam,
> >>>
> >>> IÂ’ll take it.
> >&
Hi All,
There's a typo here on line 258, where is says "Magin number" but means
"Magic number".
http://hg.openjdk.java.net/jdk/jdk/file/ec881a19d294/src/java.base/share/classes/sun/text/normalizer/ICUBinary.java
Can a committer review and correct the typo?
Thanks.
Best Regards
Adam Farley
Hi David,
Good catch. Copying to the Hotspot list.
Best Regards
Adam Farley
OpenJDK Team
Runtimes
IBM
From: David Holmes
To: Adam Farley8 , core-libs-dev
Date: 16/05/2018 22:32
Subject:Re: Bug Request: Please remove out-of-date files from bug
Done.
Though you sent
Hi All,
In bug JDK-8190187, hotspot_hg_diff and jdk_hg_diff are out-of-date.
Please can someone delete these files?
Best Regards
Adam Farley
OpenJDK Team
Runtimes
IBM
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Register
Hi All,
The code to resolve JDK-8190187 has been added to the bug, in hg_diff.txt.
Could a committer please take the fix and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and 2 for the jdwp agent ch
Bump.
Best Regards
Adam Farley
> On 13/04/2018 15:14, Adam Farley8 wrote:
> >> Hi Alan, Peter,
> >>
> >> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
> >>
> >> When t
Hi All,
Here is the code to resolve JDK-8190187:
http://cr.openjdk.java.net/~mhorie/8190187/hg_diff.txt
Could a committer please take the fix and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and 2
> On 13/04/2018 15:14, Adam Farley8 wrote:
>> Hi Alan, Peter,
>>
>> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
>>
>> When the VM adds extra memory to the allocation amount this ext
Hi All,
Here is the code to resolve JDK-8190187:
http://cr.openjdk.java.net/~mhorie/8190187/hg_diff.txt
Could a committer please take the fix and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and 2
Hi All,
I've attached the code to resolve JDK-8190187
Could a committer please take the fix (amended code attached, and
available on request) and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and 2
> On 13/04/2018 15:14, Adam Farley8 wrote:
>> Hi Alan, Peter,
>>
>> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
>>
>> When the VM adds extra memory to the allocation amount this ext
Hi Alan, Peter,
I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
When the VM adds extra memory to the allocation amount this extra bit is
not represented in the Bits total.
A cursory glance shows, minimum, that we round the
Hi All,
I've attached the code to resolve JDK-8190187
Could a committer please take the fix (amended code attached, and
available on request) and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and 2
Bump :)
Best Regards
Adam Farley
Last email
Hi Alan
Thanks for getting back to me on this. :)
I've changed the hg_diff as described below, see the attached.
> On 27/02/2018 15:04, Adam Farley8 wrote:
>
> Resending. Bump. :)
>
> On 14/02/2018 14:13, Adam Fa
Hi Alan
Thanks for getting back to me on this. :)
I've changed the hg_diff as described below, see the attached.
> On 27/02/2018 15:04, Adam Farley8 wrote:
>
> Resending. Bump. :)
>
> On 14/02/2018 14:13, Adam Farley8 wrote:
>>> Hi All,
>>>
>
Resending. Bump. :)
On 14/02/2018 14:13, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code
included
>> in the bug) and:
>>
>> 1) Complete the CSR process for the ne
the state of the Bits variables at crash-time.
Best Regards
Adam Farley
From: Alan Bateman
To: Peter Levart , Adam Farley8
Cc: "hotspot-...@openjdk.java.net developers"
, core-libs-dev
Date: 23/02/2018 17:52
Subject:Re: [PATCH] RFR Bug-pending: Enable Hots
th JFR that can snwer this? I'll put the message in IRC as
well, and
update here if I get any answers.
Best Regards
Adam Farley
From: Paul Sandoz
To: Adam Farley8
Cc: core-libs-dev , hotspot-dev
developers
Date: 22/02/2018 02:20
Subject:Re: [PATCH] RFR Bug-pending: Ena
means the DBB class+method (and anything the parsing code
mistakes for that class+method) can only ever allocate native
memory for DBBs.
What do you think?
Best Regards
Adam Farley
>
>> On Feb 14, 2018, at 3:32 AM, Adam Farley8
wrote:
>>
>> Hi All,
>>
On 14/02/2018 14:13, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code
included
>> in the bug) and:
>>
>> 1) Complete the CSR process for the new JNI Return code.
>>
On 15/02/2018 12:13 AM, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code
included
>> in the bug) and:
>>
>> 1) Complete the CSR process for the new JNI Return code.
&
Hi All,
-- Short version --
Could a committer please take the fix for JDK-8190187 (full code included
in the bug) and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain (a) the new return code, and (b) the
non-Hotspot code that handles the new code.
B
Direct Byte Buffers. This makes native memory OOM
debugging easier.
Think of it as an NMT upgrade.
Here's an example of what the output should look like:
https://developer.ibm.com/answers/questions/288697/why-does-nativememinfo-in-javacore-show-incorrect.html?sort=oldest
- Adam
>
>&
d have cc'd hotspot *and* core libs.
- Adam
>
> On 14/02/2018 9:32 PM, Adam Farley8 wrote:
>> Hi All,
>>
>> Currently, diagnostic core files generated from OpenJDK seem to lump
all
>> of the
>> native memory usages together, making it near-impossible for so
Hi All,
Currently, GenModuleInfoSource.java does not allow you to merge extra
module-info files into the primary module-info file (for a given module)
at build time.
Put simply; I think it should have this functionality. Can committers
please review and opine?
You can already see this code ch
Hi All,
We have a bug in OpenJDK where if you pass an info-only option (like
-agentlib:jdwp=help) in through the JNI interface, it can exit your code
with RC 0.
I think this is a bug because if you planned to do anything after starting
a Java VM, you have to do it in an exit hook.
If an info-
p has sailed and we're unlikely to
want to invest the time and effort in trying to clean
this up this way.
From: David Holmes
To: Adam Farley8
Cc: Alan Bateman ,
core-libs-dev@openjdk.java.net, hotspot-runtime-...@openjdk.java.net,
thomas.stu...@gmail.com
Date: 25/
1 - 100 of 109 matches
Mail list logo
