On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 115 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> - JDK-8262491: bsd_aarch64 part
>> - JDK-826300
On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 115 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> -
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley wrote:
>>> @theRealAph, could you elaborate on what is need to be done for [#2200
>>> (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
>>
>> I think that what you've got now is fi
On Fri, 12 Mar 2021 16:32:10 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 105 commits:
>>
>> - Merge commit 'refs/pull/11/head' of https://github.com/
On Tue, 9 Mar 2021 18:01:11 GMT, Anton Kozlov wrote:
>> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
>>
>>> 60:
>>> 61: #if defined(__APPLE__) || defined(_WIN64)
>>> 62: #define R18_RESERVED
>>
>> #define R18_RESERVED true```
>
> We always check for `R18_RESERVED` with `#if(n
On Tue, 9 Mar 2021 16:12:36 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Mar 2021 17:39:28 GMT, Gerard Ziemski wrote:
> A list of the bugs that our internal testing revealed so far:
Are any of these blockers for integration? Some of them are to do with things
like features that aren't yet supported, and we can't fix what we can't see.
-
PR: h
On Fri, 12 Feb 2021 11:42:59 GMT, Vladimir Kempik wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194:
>>
>>> 192: // may get turned off by -fomit-frame-pointer.
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194: return frame(fr->link(), fr->link(), fr->sender_pc(
On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 5 Feb 2021 17:20:55 GMT, Anton Kozlov wrote:
>> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93:
>>
>>> 91: CPU_MARVELL = 'V',
>>> 92: CPU_INTEL = 'i',
>>> 93: CPU_APPLE = 'a',
>>
>> The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture
>>
On Thu, 4 Feb 2021 23:01:52 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>
On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Tue, 16 Feb 2021 06:24:05 GMT, Vladimir Kempik wrote:
>> This is when passing a float, yes? In the case where we have more float
>> arguments than n_float_register_parameters_c.
>> I don't understand why you think it's acceptable to bail in this case. Can
>> you explain, please?
>
> it's for
On Mon, 15 Feb 2021 17:45:32 GMT, Anton Kozlov wrote:
>> I'm not sure it can wait. This change turns already-messy code into
>> something significantly messier, to the extent that it's not really good
>> enough to go into mainline.
>
> The latest merge with JDK-8261071 should resolve the issue.
On Mon, 15 Feb 2021 18:00:50 GMT, Vladimir Kempik wrote:
>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839:
>>
>>> 837: // The code unable to handle this, bailout.
>>> 838: return -1;
>>> 839: #endif
>>
>> This looks like a bug to me. The caller doesn't necessari
On Thu, 4 Feb 2021 23:05:56 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>
On Thu, 4 Feb 2021 09:49:17 GMT, Vladimir Kempik wrote:
> > You read my mind, Andrew. Unless, of course, it's optimized to leverage the
> > fact that it's thread-specific..
>
> it's thread-specific
>
> https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_ap
On Tue, 2 Feb 2021 18:03:50 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271:
>
>> 5269: //
>> 527
On Tue, 2 Feb 2021 21:49:36 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323:
>
>> 321: str(
On Sun, 31 Jan 2021 20:14:01 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
is some cleanup work to be done in mainline
on slow_signature_handler, which will potentially make the AArch64
back end merge much simpler.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Sun, 24 Jan 2021 15:50:01 GMT, Anton Kozlov wrote:
>> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:
>>
>>> 84:
>>> 85: switch (_num_int_args) {
>>> 86: case 0:
>>
>> I don't think you need such a large switch statement. I think this can be
>> expressed as
>> if (num_int_ar
On Sun, 24 Jan 2021 16:10:44 GMT, Anton Kozlov wrote:
>> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:
>>
>>> 392:
>>> 393: class SlowSignatureHandler
>>> 394: : public NativeSignatureIterator {
>>
>> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the
On Sun, 24 Jan 2021 16:29:31 GMT, Vladimir Kempik wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:
>>
>>> 5270: void MacroAssembler::get_thread(Register dst) {
>>> 5271: RegSet saved_regs = RegSet::range(r0, r1) +
>>> BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>>> 527
On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote:
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new ca
endencies, would be a price too high to pay for this.
> And modifying the code to work without c++11 features doesn't seem feasible.
It does seem like a lot of work. maybe the issue is that HarfBuzz is no
longer supported, and wouldn't get critical updates.
--
Andrew Haley (he/hi
create a webrev which reverts the patch,
and mark it jdk8u-critical-request.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 23/12/16 11:15, Sergey Bylokhov wrote:
> Note that if -03 will be enabled directly via OPTIMIZATION flag then the
> performance will not be improved.
Isn't this usually compiled with -O3?
Andrew.
On 28/05/15 21:33, Jim Graham wrote:
> The only viable reason for switching to memmove is to either silence the
> tool that reported the issue or to fix the data ordering issue.
Or to remove the UB. Your opinion that UB is constrained is wrong in
principle and dangerous in practice. It is extr
On 28/05/15 01:06, Jim Graham wrote:
> Where do you see evidence that it can crash?
It's what the language specification says. Undefined behaviour is
unconstrained: it can do anything. Demons might fly out of your nose.
We have seen with GCC that apparently "harmless" code (a read just
beyond t
On 05/27/2015 11:36 AM, Sergey Bylokhov wrote:
> On 26.05.15 21:27, Jim Graham wrote:
>> Undefined doesn't mean "may crash" in this case, it means that the
>> contents of memory may not match what you would expect if the regions
>> overlap because it is just a dump copy loop that does not do any
On 02/19/2015 11:35 AM, dalibor topic wrote:
> On 15.02.2015 13:39, Laurent Bourgès wrote:
>> Mario & andrews,
>>
>> Thanks for your prompt answers.
>>
>> > I agree with Andrew, getting the JEP proposed is the minimum
>> > requirement to get this work unstuck.
>>
>> Ok, so it is the way to go.
>>
On 14/02/15 14:05, Laurent Bourgès wrote:
> Following our discussions during last FOSDEM, could you tell me how to
> proceed in improving the java2d rasterizer (JEP or patches) ?
> Who could help me on that topic (patch, review, test...) ?
Creating a JEP is super-easy: you just have to follow the
On 05/07/2013 09:44 AM, Laurent Bourgès wrote:
> I confirm oprofile (0.96 on my fedora 14) works just fine (see below).
>
> Do you recommend me to use the latest (git) version ? 0.96 is quite old
> (2011)
Only if the version you're using doesn't work.
> Could you explain me a bit how to get sam
On 05/06/2013 04:12 PM, Laurent Bourgès wrote:
> Could you give advices on how to use it with custom OpenJDK builds, andrew
IME it Just Works. The oprofile shipped with Linux distros has
everything you need, and you just need to use -agentpath: when you
start the VM.
Andrew.
On 05/06/2013 04:07 PM, Laurent Bourgès wrote:
> I want to have good metrics related to java code (not native) so I need a
> java profiler.
Oprofile works well with Java code. The JIT compiler has enough smarts
to register dynamically-generated code with oprofile, and you get the
added benefit t
On 05/06/2013 10:46 AM, Laurent Bourgès wrote:
> Dear Dalibor, Donald and java2d members,
>
> I am currently working hard to improve performances of the pisces java2d
> renderering engine.
>
> To help me improving cpu hotspots, I need an efficient java profiler (lower
> overhead than netbeans pro
On 07/12/2012 01:09 PM, Claudio Wilmanns wrote:
> Moreover it is possible that the support for the absolute colorimetric
> rendering intent has been stripped in the Java version of the Kodak CMM -
> although this may be true for littleCMS as well.
It's not stripped, but AFAIK there's no Java inter
On 07/12/2012 02:40 PM, Claudio Wilmanns wrote:
>> You know the whitepoints of your source space and your target space:
>> they're in the colour profiles. Create a matrix that is the inverse
>> of the transform from source to target whitepoint and apply it to your
>> source image. Then do your re
On 07/12/2012 01:59 PM, Claudio Wilmanns wrote:
> If I understand you right, JNI gives me access to the Kodak CMM¹s C
> interface. OK, that¹s interesting. But I assume that there is some
> overhead involved in converting a Java image buffer to a format the CMM
> interface understands. Anyway, I fo
On 05/29/2012 02:50 PM, Phil Race wrote:
> I have one concern
>
> It sounds like the option is new in gcc 4.4 :
> http://gcc.gnu.org/gcc-4.4/porting_to.html
>
> I am not sure you can assume that since ..
>
> http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#gcc
> " The GNU gc
On 05/29/2012 06:12 PM, Kelly O'Hair wrote:
>
> You should be able to do something like:
>
> # Turn off aliasing with GCC for ExtensionSubtables.cpp
> ifeq ($(PLATFORM), linux)
> CXXFLAGS += $(CXXFLAGS_$(@F))
> CC_NEWER_THAN_43 := \
> $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \
>
This is a heads up.
I've been looking at the failing CMM jtreg tests, and I think I have a
solution.
The problems are:
1. Some incorrect "golden" images: these have errors, presumably
caused by bugs in whatever CMM was used to create them.
2. In the case of PYCC, some of the entries in the go
Mario Torre wrote:
> Hello all!
>
> I have a problem with a block of code that checks if _LITTLE_ENDIAN is
> defined, the code is in little cms and looks like:
>
> #ifndef _LITTLE_ENDIAN
> #define USE_BIG_ENDIAN 1
> #endif
>
> The issue that I have is that on VxWorks, the target I'm working on
bugzilla-dae...@bugs.openjdk.java.net wrote:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100050
>
> --- Comment #9 from jennifer.godi...@sun.com 2009-05-20 10:10:27 PDT ---
> Hi Andrew,
>
> The fix has been approved. If you want to push the fix yourself, here's the
> suggested commit comment
Phil Race wrote:
> Andrew Haley wrote:
>> Phil Race wrote:
>>
>> The bug is at https://bugs.openjdk.java.net/show_bug.cgi?id=100050, with
>> a suggested patch attached to it. Please have a look and let me know if
>> I can push the patch to 6-open and jdk7. If y
Phil Race wrote:
>
> Andrew Haley wrote:
>> Phil Race wrote:
>>> I recall that we refactored the patch to touch fewer of the littlecms
>>> internals. This helped since just 4 days after that patch the littlecms
>>> version was upgraded from 1.16 to 1.18. I&#
Phil Race wrote:
> I recall that we refactored the patch to touch fewer of the littlecms
> internals. This helped since just 4 days after that patch the littlecms
> version was upgraded from 1.16 to 1.18. I'd be surprised if you have
> only this patch and not the littlecms 1.18 patch. Maybe its 1.1
I've been getting JCK failures in lcms, and it seems to be down to
this changset:
changeset: 1010:467e4f25965c
user:avu
date:Fri Mar 20 20:05:22 2009 +0300
summary: 6733501: Apply IcedTea little cms patches
The bug points to the webrev at
http://mail.openjdk.java.net/piperma
The JCK revealed a race condition in UnixPrintServiceLookup when either
sun.java2d.print.polling=false or getDefaultPrintService() returns
before the polling PrintServices thread has started. This causes
multiple copies of IPPPrintService to be instantiated. The test below
fails on all platforms
Ben Loud wrote:
> I know what you mean. I would like to see more comprehensive support
> for color management in the JDK. Right now all we get is
> to/fromXYZ() which is defined to be done using relative
> colorimetric, and to/fromsRGB, which is defined to use perceptual,
> but these only work on
Jerry Evans wrote:
> Andrew Haley wrote:
>
>> sRGB data is (a function similar to) raising to the power 2,2,
>> so to go from linear RGB to sRGB is
>> Math.pow(x/255, 1/2.2) * 255
>>
>>
>> When light levels are very low the transfer function is ve
Phil Race wrote:
> Andrew,
>
> I think we just need to verify how well these work.
> How did you verify them?
> Did you run any of the tests in test/sun/java2d/cmm ?
There are some failures, but I don't believe that's entirely
due to any problem in lcms and/or my profiles.
For example, consider
Phil Race wrote:
> Andrew,
>
> I think we just need to verify how well these work.
> How did you verify them?
> Did you run any of the tests in test/sun/java2d/cmm ?
No, I didn't. I just did a few basic smoke tests.
I'll do that and let you know.
Andrew.
> A
Andrew Haley wrote:
> Phil Race wrote:
>> I guess rather than sending several hundred kbytes of binaries to
>> the list, you could just email them directly to someone here at Sun.
>> You can send them to me if you like. You can send both pycc.pf's but
>> most like
Phil Race wrote:
> I guess rather than sending several hundred kbytes of binaries to
> the list, you could just email them directly to someone here at Sun.
> You can send them to me if you like. You can send both pycc.pf's but
> most likely the 229K byte PYCC one is the one that will get used.
> Th
Phil Race wrote:
> I guess rather than sending several hundred kbytes of binaries to
> the list, you could just email them directly to someone here at Sun.
> You can send them to me if you like.
OK.
> You can send both pycc.pf's but most likely the 229K byte PYCC one
> is the one that will get u
Alexey Ushakov wrote:
> Hello Andrew,
>
>> One final thought: we could implement some of these standard colour
>> spaces
>> by subclassing ColorSpace directly without the use of any underlying
>> colour profile. This would be more accurate than lcms in many cases, and
>> might even be faster in s
faster in some.
So, where should I send these profiles?
Andrew.
> Andrew Haley wrote:
>> Andrew Haley wrote:
>>> Just a heads-up: I'm working on Bug 6523403, Need to provide lcms
>>> library with PYCC and LINEAR_RGB OS ICC profiles. I'm also looking
>>> at
Andrew Haley wrote:
> Just a heads-up: I'm working on Bug 6523403, Need to provide lcms
> library with PYCC and LINEAR_RGB OS ICC profiles. I'm also looking
> at the causes of Bug 6523402, Some quality problems with GRAY, PYCC
> and CIEXYZ color spaces with lcms library
Just a heads-up: I'm working on Bug 6523403, Need to provide lcms
library with PYCC and LINEAR_RGB OS ICC profiles. I'm also looking
at the causes of Bug 6523402, Some quality problems with GRAY, PYCC
and CIEXYZ color spaces with lcms library
I have created a LINEAR_RGB profile using the same pri
62 matches
Mail list logo
