On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang wrote:
>> Remove the redundant `@enablePreview` and `--enable-preview` flags for
>> enabling ClassFile API in the tests. The remainder of these flags in all
>> tests seem to serve preview APIs (such as ScopedValue) or language features
>> (primitive
On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang wrote:
>> Remove the redundant `@enablePreview` and `--enable-preview` flags for
>> enabling ClassFile API in the tests. The remainder of these flags in all
>> tests seem to serve preview APIs (such as ScopedValue) or language features
>> (primitive
On Thu, 5 Dec 2024 22:26:31 GMT, Chen Liang wrote:
>> test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> line 643:
>>
>>> 641:
>>> 642: Task.Result result = new JavacTask(tb)
>>> 643: .processors(new TestAP())
>>
>> I assume this fix does not
On Thu, 5 Dec 2024 21:54:19 GMT, Mandy Chung wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/jdk into
>> cleanup/cf-preview
>> - 8334
On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang wrote:
>> Remove the redundant `@enablePreview` and `--enable-preview` flags for
>> enabling ClassFile API in the tests. The remainder of these flags in all
>> tests seem to serve preview APIs (such as ScopedValue) or language features
>> (primitive
On Wed, 4 Dec 2024 20:20:16 GMT, Simon Tooke wrote:
>> This is a port of #16301 to macOS.
>>
>> System.map and System.dump_map are implemented using the macOS API and
>> provide roughly the same information in the same format. Most of the heavy
>> lifting was implemented by @tstuefe in
>> ht
> Remove the redundant `@enablePreview` and `--enable-preview` flags for
> enabling ClassFile API in the tests. The remainder of these flags in all
> tests seem to serve preview APIs (such as ScopedValue) or language features
> (primitive pattern, module imports, etc.), or testing the enable pr
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Thu, 5 Dec 2024 17:45:06 GMT, Thomas Stuefe wrote:
>> Simon Tooke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix trailing whitesdpae errors
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 99:
>
>> 97: if (valid_share_mo
On Thu, 5 Dec 2024 17:41:00 GMT, Thomas Stuefe wrote:
>>> @tstuefe I ran an experiment with raw mmap, and there's no way to
>>> differentiate between one large allocation of 5*128MB and 5 smaller
>>> allocations of 128MB. I _could_ add code to fold these, but we risk loosing
>>> information.
>
> This is a port of #16301 to macOS.
>
> System.map and System.dump_map are implemented using the macOS API and
> provide roughly the same information in the same format. Most of the heavy
> lifting was implemented by @tstuefe in
> https://github.com/openjdk/jdk/pull/16301 - this PR adds the m
> This is a port of #16301 to macOS.
>
> System.map and System.dump_map are implemented using the macOS API and
> provide roughly the same information in the same format. Most of the heavy
> lifting was implemented by @tstuefe in
> https://github.com/openjdk/jdk/pull/16301 - this PR adds the m
On Thu, 5 Dec 2024 16:04:10 GMT, Thomas Stuefe wrote:
>>> @tstuefe I've look into your test, and I will modify the PR to display
>>> these regions - it was incorrectly identifying them as "free". As to the
>>> strange vmmap behaviour, I found that the two sections appeared in
>>> different pla
On Thu, 5 Dec 2024 16:04:10 GMT, Thomas Stuefe wrote:
>>> @tstuefe I've look into your test, and I will modify the PR to display
>>> these regions - it was incorrectly identifying them as "free". As to the
>>> strange vmmap behaviour, I found that the two sections appeared in
>>> different pla
On Thu, 5 Dec 2024 14:32:53 GMT, Thomas Stuefe wrote:
>> Hi @stooke !
>>
>>> Hello, @tstuefe , and thanks for your comments. I'll address a few here
>>> while I work on the others. I have changed the os-specific names to
>>> lowercase, but I don't think it makes them stand out more. The square
On Thu, 5 Dec 2024 14:32:53 GMT, Thomas Stuefe wrote:
>> Hi @stooke !
>>
>>> Hello, @tstuefe , and thanks for your comments. I'll address a few here
>>> while I work on the others. I have changed the os-specific names to
>>> lowercase, but I don't think it makes them stand out more. The square
On Thu, 5 Dec 2024 15:16:46 GMT, Chen Liang wrote:
>> I had hoped to keep the change focused on the removal of the left over
>> ReflectUtil.checkPackageAccess, the else throw AssertionError was a surprise
>> to see. So yes, I agree it can be removed but I'd prefer not touch it now,
>> future w
On Thu, 5 Dec 2024 10:20:50 GMT, Alan Bateman wrote:
> We hollowed out ReflectUtil as one of the early steps when removing the code
> for running in the SecurityManager execution mode. Most of the usages have
> now been removed so the empty (and unused) methods can be removed. FieldUtils
> and
On Thu, 5 Dec 2024 14:50:53 GMT, Chen Liang wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright header end dates
>
> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.
On Thu, 5 Dec 2024 15:01:27 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
>> line 138:
>>
>>> 136: assert genericDeclaration instanceof Class ||
>>> 137: genericDeclaration instanceof Method ||
>>> 13
On Thu, 5 Dec 2024 14:46:14 GMT, Alan Bateman wrote:
>> We hollowed out ReflectUtil as one of the early steps when removing the code
>> for running in the SecurityManager execution mode. Most of the usages have
>> now been removed so the empty (and unused) methods can be removed.
>> FieldUtils
On Thu, 5 Dec 2024 14:46:14 GMT, Alan Bateman wrote:
>> We hollowed out ReflectUtil as one of the early steps when removing the code
>> for running in the SecurityManager execution mode. Most of the usages have
>> now been removed so the empty (and unused) methods can be removed.
>> FieldUtils
On Thu, 5 Dec 2024 14:46:14 GMT, Alan Bateman wrote:
>> We hollowed out ReflectUtil as one of the early steps when removing the code
>> for running in the SecurityManager execution mode. Most of the usages have
>> now been removed so the empty (and unused) methods can be removed.
>> FieldUtils
> We hollowed out ReflectUtil as one of the early steps when removing the code
> for running in the SecurityManager execution mode. Most of the usages have
> now been removed so the empty (and unused) methods can be removed. FieldUtils
> and ConstructorUtils can be removed too.
>
> ObjectInputS
On Thu, 5 Dec 2024 10:20:50 GMT, Alan Bateman wrote:
> We hollowed out ReflectUtil as one of the early steps when removing the code
> for running in the SecurityManager execution mode. Most of the usages have
> now been removed so the empty (and unused) methods can be removed. FieldUtils
> and
On Mon, 2 Dec 2024 14:52:38 GMT, Thomas Stuefe wrote:
>> Hello, @tstuefe , and thanks for your comments. I'll address a few here
>> while I work on the others.
>> I have changed the os-specific names to lowercase, but I don't think it
>> makes them stand out more. The square brackets were int
On Thu, 5 Dec 2024 10:20:50 GMT, Alan Bateman wrote:
> We hollowed out ReflectUtil as one of the early steps when removing the code
> for running in the SecurityManager execution mode. Most of the usages have
> now been removed so the empty (and unused) methods can be removed. FieldUtils
> and
We hollowed out ReflectUtil as one of the early steps when removing the code
for running in the SecurityManager execution mode. Most of the usages have now
been removed so the empty (and unused) methods can be removed. FieldUtils and
ConstructorUtils can be removed too.
ObjectInputStream/Object
28 matches
Mail list logo
