from:"Dean"

On Fri, 17 May 2024 at 09:22, Dean Rasheed  wrote:
>
> On Wed, 15 May 2024 at 02:14, Erik Wienhold  wrote:
> >
> > plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
> >
> > Fixed in the attached patch.
> >
>
> Nice catch! The patch looks good to me on a quick read-through.
>
> I'll take a closer look next week, after the beta release, since it's
> a v16+ bug.
>

(finally got back to this)

Committed and back-patched to v16. Thanks for the report and patch.

Regards,
Dean

pgsql: Fix PL/pgSQL's handling of integer ranges containing underscores

Fix PL/pgSQL's handling of integer ranges containing underscores.

Commit faff8f8e47 allowed integer literals to contain underscores, but
failed to update the lexer's "numericfail" rule. As a result, a
decimal integer literal containing underscores would fail to parse, if
used in an integer range with no whitespace after the first number,
such as "1_001..1_003" in a PL/pgSQL FOR loop.

Fix and backpatch to v16, where support for underscores in integer
literals was added.

Report and patch by Erik Wienhold.

Discussion: https://postgr.es/m/808ce947-46ec-4628-85fa-3dd600b2c154%40ewie.name

Branch
--
REL_16_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/b4e909082fa114d5934ca622b225d2352ec639fa

Modified Files
--
src/backend/parser/scan.l|  2 +-
src/fe_utils/psqlscan.l  |  2 +-
src/interfaces/ecpg/preproc/pgc.l|  2 +-
src/test/regress/expected/numerology.out | 11 +++
src/test/regress/sql/numerology.sql  |  9 +
5 files changed, 23 insertions(+), 3 deletions(-)

pgsql: Fix PL/pgSQL's handling of integer ranges containing underscores

Fix PL/pgSQL's handling of integer ranges containing underscores.

Commit faff8f8e47 allowed integer literals to contain underscores, but
failed to update the lexer's "numericfail" rule. As a result, a
decimal integer literal containing underscores would fail to parse, if
used in an integer range with no whitespace after the first number,
such as "1_001..1_003" in a PL/pgSQL FOR loop.

Fix and backpatch to v16, where support for underscores in integer
literals was added.

Report and patch by Erik Wienhold.

Discussion: https://postgr.es/m/808ce947-46ec-4628-85fa-3dd600b2c154%40ewie.name

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/cd2624fd97b0c36b68da278abc5362647f69b07d

Modified Files
--
src/backend/parser/scan.l|  2 +-
src/fe_utils/psqlscan.l  |  2 +-
src/interfaces/ecpg/preproc/pgc.l|  2 +-
src/test/regress/expected/numerology.out | 11 +++
src/test/regress/sql/numerology.sql  |  9 +
5 files changed, 23 insertions(+), 3 deletions(-)

Re: Minor fixes for couple some comments around MERGE RETURNING

On Thu, 23 May 2024 at 04:26, David Rowley  wrote:
>
> On Sun, 19 May 2024 at 15:20, David Rowley  wrote:
> >
> > I noticed that PlannedStmt.hasReturning and hasModifyingCTE have an
> > outdated comment now that MERGE supports RETURNING (per commit
> > c649fa24a)
> >
> > i.e. these two:
> >
> > > bool hasReturning; /* is it insert|update|delete RETURNING? */
> >
> > > bool hasModifyingCTE; /* has insert|update|delete in WITH? */
>
> I've pushed the fix for that.
>

Thanks for taking care of that.

I found another couple of similar comments that also needed updating,
so I've pushed a fix for them too.

Regards,
Dean

pgsql: Fix another couple of outdated comments for MERGE RETURNING.

Fix another couple of outdated comments for MERGE RETURNING.

Oversights in c649fa24a4 which added RETURNING support to MERGE.

Discussion: 
https://postgr.es/m/caaphdvpqp6vtuzg-_josueibgyqnrnvxj-vdf+hjlxjhdhz...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/5c5bccef211cfc98e0d6c4bc1af40a33c8ac2488

Modified Files
--
src/backend/utils/adt/ruleutils.c | 2 +-
src/include/nodes/parsenodes.h| 2 +-
src/include/utils/portal.h| 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)

Keyboard shortcut binding issues

2024-06-03 Thread Michael Dean Pugh

Hello!

I just upgraded to 2.4, something I have been looking forward to doing for 
quite a while.  I am having a minor problem that may be a bug.  I had added 
quite a few additional keyboard shortcuts which LyX stored in a user.bind file 
in the bind subdirectory of the user directory.  The old version of LyX 
apparently knew about this file and the default cua file simultaneously.  In 
the new version, it appears to be one or the other.  When the bind file is set 
to cua (as it was in 2.3.7) none of the new shortcuts work.  But here's the 
kicker: those new shortcuts are visible under Preferences -> Editing -> 
Shortcuts.  So LyX seems to see the file, it just does not allow me to use 
those shortcuts when the bind file is set to cua.  If I change it to user, 
which I did not need to do before, the new shortcuts work, but none of the 
default ones—like copy and paste—do.  I can probably merge the two files into 
the user.bind file as a workaround, but is this a bug or is there something I 
am forgetting to do?

Thanks!
Mike Pugh
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

[mailop] Microsoft failing to connect?

2024-05-30 Thread Dean Walsh via mailop

Hi All,

We're seeing a weird issue with random servers on our network failing to 
connect from Microsoft. It's only some prefixes, and only seems to be affecting 
Microsoft.

Is anyone else having this problem? I've been unable to have someone from 
Microsoft investigate further.

Reason: [{LED=450 4.4.316 Connection refused [Message=Socket error code 10061] 
[LastAttemptedServerName=*.com.au] [LastAttemptedIP=175.45.181.241:25] 
[SmtpSecurity=-2;-2] [ME3AUS01FT009.eop-AUS01.prod.protection.outlook.com 
2024-05-30T08:53:30.378Z 08DC805114847D2D]};{MSG=Socket error code 
10061};{FQDN=**};{IP=17. OutboundProxyTargetIP: 175.45.181.241. 
OutboundProxyTargetHostName: .com.au


I've tried with the firewall disabled and no RBL blocking, it still fails to 
connect with the same socket error code.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[Cscwg-public] CSC-24 (v3): Timestamping Private Key Protection: BALLOT RESULTS

2024-05-29 Thread Dean Coclin via Cscwg-public

Voting on Ballot CSC-24 has ended and the ballot has FAILED.

 

CAs voting in favor: DigiCert, Entrust, Globalsign, Harica, Identrust, Sectigo

Opposed: None

Abstain: None

 

Certificate Consumers voting in favor: None

Opposed: None

Abstain: None

 

Quorum = 5 and was met.

 

Therefore the ballot fails.

 

The proposer and endorsers are urged to review the ballot and coordinate a 
re-vote.


Dean Coclin

CSCWG Char

 

From: Cscwg-public  On Behalf Of Martijn 
Katerbarg via Cscwg-public
Sent: Monday, May 20, 2024 11:05 AM
To: cscwg-public@cabforum.org
Subject: [Cscwg-public] [Voting Period Begins] CSC-24 (v3): Timestamping 
Private Key Protection

 

Purpose of the Ballot

This ballot updates the “Baseline Requirements for the Issuance and Management 
of Publicly‐Trusted Code Signing Certificates“ version 3.7 in order to clarify 
language regarding Timestamp Authority Private Key Protection. The main goals 
of this ballot are to:

1.  Require Private Keys  associated with newly issued Timestamp Authority 
Subordinate CA to be stored in offline HSMs
2.  Require newly issued Timestamp Certificates to be issued from a TSA CA 
with its Private key storedn in offline HSMs
3.  Add a requirement to remove Private Keys associated with Timestamp 
Certificates after a 18 months
4.  Add a requirement to reject SHA-1 timestamp requests

The following motion has been proposed by Martijn Katerbarg of Sectigo and 
endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft.

 

MOTION BEGINS

 

This ballot updates the “Baseline Requirements for the Issuance and Management 
of Publicly‐Trusted Code Signing Certificates” ("Code Signing Baseline 
Requirements") based on version 3.7. MODIFY the Code Signing Baseline 
Requirements as specified in the following redline: 
https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...61d9426e9025d448a13eb56fa75b9651b2136548
 
<https://url.avanan.click/v2/___https:/github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...61d9426e9025d448a13eb56fa75b9651b2136548___.YXAzOmRpZ2ljZXJ0OmE6bzo1ZGE3YzY1NjUwNWIyZGVhNWFlYjA3MDM4NTg0ODhiZDo2OmUwN2Y6NmJlZWIyODY3YTc4YzliYWY0MWNiMjJhNTlkMDIxNTA1YmVkZTIwNjUwMmRhYzM4ZDgxNDNhMGI2NjdkMzdiNzpoOkY>
  

MOTION ENDS

The procedure for this ballot is as follows:

Discussion (7 days)

*   Start Time: 2024-05-10 10:45 UTC
*   End Time: Not before 2024-05-20 09:05 UTC

Vote for approval (7 days)

*   Start Time: 2024-05-20 09:05 UTC
*   End Time: 2024-05-27 09:05 UTC

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: View / test *-ttf fonts

2024-05-25 Thread Thomas D. Dean


On 5/25/24 07:22, Todd Gruhn wrote:

Is there a way to view the *-ttf fonts?
So I know what it will look like ...


xfd

Tom Dean

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]

2024-05-22 Thread Dean Long

On Wed, 22 May 2024 14:28:41 GMT, Yudi Zheng  wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693:
>> 
>>> 4691: const Register xlen  = r1;
>>> 4692: const Register z = r2;
>>> 4693: const Register zlen  = r3;
>> 
>> LibraryCallKit::inline_squareToLen() is still computing zlen and passing it 
>> as the 4th arg, even though the value is unused.
>
> ppc x86 are not using `multiply_to_len` for `generate_squareToLen`. I think 
> we still need to pass zlen for these platforms.

OK.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1610580527

Re: plpgsql: fix parsing of integer range with underscores

2024-05-17 Thread Dean Rasheed

On Wed, 15 May 2024 at 02:14, Erik Wienhold  wrote:
>
> plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
>
> Fixed in the attached patch.
>

Nice catch! The patch looks good to me on a quick read-through.

I'll take a closer look next week, after the beta release, since it's
a v16+ bug.

Regards,
Dean

Re: avoid MERGE_ACTION keyword?

2024-05-17 Thread Dean Rasheed

On Thu, 16 May 2024 at 15:15, Peter Eisentraut  wrote:
>
> I wonder if we can avoid making MERGE_ACTION a keyword.
>

Yeah, there was a lot of back and forth on this point on the original
thread, and I'm still not sure which approach is best.

> I think we could parse it initially as a function and then transform it
> to a more special node later.  In the attached patch, I'm doing this in
> parse analysis.  We could try to do it even later and actually execute
> it as a function, if we could get the proper context passed into it somehow.
>

Whichever way it's done, I do think it's preferable to have the parse
analysis check, to ensure that it's being used in the right part of
the query, rather than leaving that to plan/execution time.

If it is turned into a function, the patch also needs to update the
ruleutils code --- it needs to be prepared to output a
schema-qualified function name, if necessary (something that the
keyword approach saves us from).

Regards,
Dean

[Cscwg-public] Final CSCWG May 2nd, 2024 Minutes

2024-05-16 Thread Dean Coclin via Cscwg-public

Attendees:
Dimitris (HARICA),
Corey Bonnell (DigiCert),,
Thomas Zermeno (SSL.com),
Scott Rea (eMudhra),
Bruce Morton (Entrust),
Andrea Holland (VikingCloud),
Rebecca Kelley (SSL.com),
Brian Winters (IdenTrust),
Ian McMillan (Microsoft),
Mohit Kumar (GlobalSign),
Marco Schambach (IdenTrust),
Richard Kisley (IBM),
Brianca Martin (Amazon),
Martijn Katerbarg (Sectigo),
Wangmo Tenzing (Wangmo Tenzing),
Tim Hollebeek (DigiCert),
Janet Hines (VikingCloud),
Atsushi INABA (GlobalSign),
Dean Coclin (DigiCert),
Inigo Barreira (Sectigo),
Janet Hines (VikingCloud)

Minute-taker: Brian Winters

AntiTrust Reminder read by Dean Coclin.


Face-to-face meeting minutes approved.

April 18th Minutes approved.


* EVCS Guidelines ballot CSC-23:

Bruce Morton indicated possible new requirement raised by Martijn.  Martijn
requested input by Dimitris, not on the call yet.
Cory stated that the language sometimes indicates EV Code Signing
certificate and in other places uses the term certificates.
Bruce asked what is the new requirement?  Cory indicated the Subject Org ID
requirement.  We are introducing new language about what the Org ID may
contain.
Bruce suggested a new ballot regarding the Org ID changes.  Agreed upon by
Ian, and Andrea Holland.
Dean mentioned having seen an open pull request to remove the Org ID
changes.  Pull request has comments by Dimitris and Corey Bonnell.
Corey stated that Dimitris is the main driver on this ballot.

Dimitris joined late and commented on new requirement as done on purpose, to
be effective sometime after September to be consistent with new EV
guidelines.
Bruce commented Org Id might be better to add later after adapting to new MS
EV Guidelines.  Dimitris stated he is ok with removing it now and adding it
later.  But thinks it could also be added now as optional.  Cory expressed
some customers might be already using Org Id and may have incompatibilities
with new Org Id standards.  Dimitris stated the September effective date
allows time for those customers to adapt.  Andrea asked Dimitris if it's
acceptable to create a separate ballot for the Org Id field.  Tim commented
achieving parity with TLS working group might be just updating requirements
for sake of updating requirements.  We should really solve the problem.  We
should find the best way to identify the globally unique publisher signing
code.  Most relying party software doesn't utilize Org Id field.  Tim urged
separating this into a new ballot.  Dimitris eventually agreed.

Bruce asked Dimitris about the Due Diligence requirement.  Martijn commented
about portions of it being in scope.  Expressed concern about the term
Nullified in the language.


* Timestamping Ballot CSC-24

Martijn raised topic about language to prevent CAs from issuing Timestamp
certificates from already issued SubCAs in an online state.  Language was
introduced on April 22nd, yet no comments produced.  Planned to effect
certificates issued on or after April 15, 2025.


* Face-to-Face meeting planning

Dean Coclin asked for suggestions for items to discuss.

- Ian suggested the topic "maximum certificate validity periods for CS
certificates".  Impact of reducing max validity from 39 to 15 or 24 months
duration.  What is the sweat spot for max validity periods.
- Bruce wants to discuss Microsoft's planned changes to EV CS certificates.
Ian agreed this is an important topic.  Tentative plan is one certificate
type, albeit Individual validated and Organization validated.  Dean pointed
out another notable example of Microsoft EV CS use hardware related
scenario.
- Corey raised issue regarding Microsoft's Trusted Signing Service
introduces custom EKU into CS certificates to uniquely identify the
publisher (face-to-face or future meeting).  Potential breakage for
publisher.  Per publisher EKU is potential solution to prevent breakage.
Ian discussed Windows Security Center involvement on this issue.  Only 1st
party CAs for integrity checks.
- Martijn,  CT for code signing time allowing.

* Other business

Next Meeting May 16th.

Following will be the Face-to-face meeting in Italy.

* Topic for next meeting

- PCI-HSM Acceptance for CA HSM evaluations (Richard Kisley).


smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: [LincolnTalk] state moving bear from Lincoln - Process? Bear Dens?

2024-05-15 Thread dean stillings

If you read Linda Macmillan’s post which is below. You would know that the
bear did not get moved to Lincoln by the state. That he had moved 35 miles
in the last week.
Thank you
Dean

On Wed, May 15, 2024 at 11:53 AM ROY HARVEY  wrote:

> Franklin Park is planning "safety improvements" to upgrade the Bear Dens:
> www.boston.gov/improvements-franklin-park-bear-dens
>
> Does anyone know the process by which the state determines when and where
> to move a bear?
>
> If so, can the Select Board or Town Meeting request them to do so?
>
>
> Roy
>
> On 05/15/2024 9:39 AM EDT Rich Rosenbaum  wrote:
>
>
> Not just LIncoln.
>
> https://massbears.wordpress.amherst.edu/
>
>
>
> On Wed, May 15, 2024 at 9:27 AM Sasha Golden 
> wrote:
>
> Maybe the bear was hoping for more upscale housing?
>
> On Wed, May 15, 2024 at 9:13 AM Margaret Olson 
> wrote:
>
> As you can see from Linda McMillan's post below, the state did not move
> the bear to Lincoln. It moved the bear to some undisclosed location 35
> miles from here. The bear, which has four legs and can run at 25 to 35
> miles per hour, came to Lincoln. It's a nice town :-)
>
> Margaret
>
>
> On Wed, May 15, 2024 at 8:26 AM Anne Warner 
> wrote:
>
> I am taken aback that the state “moved the bear from Worcester” to
> Lincoln. Did we consent to that?  People are now having to supervise their
> children playing outside and take down their bird feeders which, at least
> in our house, are a source of real joy. I think we should call on our
> Select Board to push back on this, and get the bear “moved” to an area
> where there is much more unoccupied land for them to forage. The bear might
> be cute, but these are wild animals and although this one has not attacked
> anyone, I don’t think we should have to worry about our children playing
> outside. Anne Warner
> - Sent from iPhone. Typed by thumb. Excuse misspellings!
>
> On May 13, 2024, at 7:07 PM, Linda McMillan 
> wrote:
>
> I talked with the Massachusetts bear biologist today. He said this bear
> was moved from Worcester where he was wandering into a very developed area
> not because he was aggressive or violent. He's about two years old and has
> moved about 35 miles in the last week. They have no intention of moving him
> out of Lincoln. He said we should get used to having bears in our town. The
> likelihood is that we will see more.
>
> He said to take down your bird feeders and bring in your trash.
>
> Regarding dogs, he said there is more risk that your dog will be attacked
> by a coyote than by a bear. However, he said if you have a dog that wanders
> or does not come to you when called,  or who is aggressive,  he suggests
> keeping it on a leash.
>
> He also said there is no need to notify them of the current location
> because they have no plans to move the bear.
>
> I hope this is helpful.
>
> Linda
>
> On Mon, May 13, 2024, 5:12 PM Jennifer Saffran 
> wrote:
>
> I’ve seen bear tags before, but “Dodger” appears to have both ears tagged.
> What’s up with that?
>
> On May 12, 2024, at 9:20 PM, Joanna Owen Schmergel via Lincoln <
> lincoln@lincolntalk.org> wrote:
>
> It’s Dodger!
>
>
> Sent from Yahoo Mail for iPhone
> <https://mail.onelink.me/107872968?pid=nativeplacement=Global_Acquisition_YMktg_315_Internal_EmailSignature_sub1=Acquisition_sub2=Global_YMktg_sub3=_sub4=10604_sub5=EmailSignature__Static_>
>
> On Sunday, May 12, 2024, 9:16 PM, Lynne Smith  wrote:
>
> Looks like he has opposing thumbs ! And he clearly knows where to find
> seeds.
>
>
> Lynne Smith
> 5 Tabor Hill Road
> <https://www.google.com/maps/search/5+Tabor+Hill+Road+Lincoln,+MA+01773?entry=gmail=g>
> <https://www.google.com/maps/search/5+Tabor+Hill+Road+%0D%0A+++%0D%0A+++%0D%0ALincoln,+MA+01773?entry=gmail=g>
>
> <https://www.google.com/maps/search/5+Tabor+Hill+Road+%0D%0A+++%0D%0A+++%0D%0ALincoln,+MA+01773?entry=gmail=g>
>
> <https://www.google.com/maps/search/5+Tabor+Hill+Road+%0D%0A+++%0D%0A+++%0D%0ALincoln,+MA+01773?entry=gmail=g>Lincoln,
> MA 01773
> <https://www.google.com/maps/search/5+Tabor+Hill+Road+Lincoln,+MA+01773?entry=gmail=g>
> 781-258-1175
> Sent from my iPhone
>
> > On 12 May 2024, at 6:14 PM, pspe...@gmail.com wrote:
> >
> >
> >
> >
> >
> >
> >
> > Sent from my iPhone--
> > The LincolnTalk mailing list.
> > To post, send mail to Lincoln@lincolntalk.org.
> > Browse the archives at
> https://pa

[Cscwg-public] CSCWG Agenda May16, 2024

2024-05-14 Thread Dean Coclin via Cscwg-public

MINUTE TAKER: NEED A VOLUNTEER, START RECORDING

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - May 2 (Brian)
4.  Proposed ballots: Remove EV Guideline References (Dimitris)
5.  Proposed ballot for Time-stamp Requirements update; CSC-24 (Martijn)
6.  Proposal for PCi-HSM acceptance for CA HSMs evaluation (R.Kisley)
7.  Further discuss F2F Agenda
8.  Other business
9.  Next meeting - F2F   
10. Adjourn

 

 

Dean Coclin 

CSCWG Chair

 

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: Underscore in positional parameters?

2024-05-14 Thread Dean Rasheed

On Tue, 14 May 2024 at 07:43, Michael Paquier  wrote:
>
> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> > Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
> > the parameter number with atol which stops at the underscore.  That's a
> > regression in faff8f8e47f.  Before that commit, $1_2 resulted in
> > "ERROR: trailing junk after parameter".
>
> Indeed, the behavior of HEAD is confusing.  "1_2" means 12 as a
> constant in a query, not 1, but HEAD implies 1 in the context of
> PREPARE here.
>
> > I can't tell which fix is the way to go: (1) accept underscores without
> > using atol, or (2) just forbid underscores.  Any ideas?
>
> Does the SQL specification tell anything about the way parameters
> should be marked?  Not everything out there uses dollar-marked
> parameters, so I guess that the answer to my question is no.  My take
> is all these cases should be rejected for params, only apply to
> numeric and integer constants in the queries.
>
> Adding Dean in CC as the committer of faff8f8e47f, Peter E for the SQL
> specification part, and an open item.

I'm sure that this wasn't intentional -- I think we just failed to
notice that "param" also uses "decinteger" in the scanner. Taking a
quick look, there don't appear to be any other uses of "decinteger",
so at least it only affects params.

Unless the spec explicitly says otherwise, I agree that we should
reject this, as we used to do, and add a comment saying that it's
intentionally not supported. I can't believe it would ever be useful,
and the current behaviour is clearly broken.

I've moved this to "Older bugs affecting stable branches", since it
came in with v16.

Regards,
Dean

Re: RFR: 8330171: Lazy W^X switch implementation

2024-05-12 Thread Dean Long

On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin  wrote:

> An alternative for preemptively switching the W^X thread mode on macOS with 
> an AArch64 CPU. This implementation triggers the switch in response to the 
> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this 
> approach, it is now feasible to eliminate all WX guards and avoid potentially 
> costly operations. However, no significant improvement or degradation in 
> performance has been observed.  Additionally, considering the issue with 
> AsyncGetCallTrace, the patched JVM has been successfully operated with 
> [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and 
> [async-profiler](https://github.com/async-profiler/async-profiler). 
> 
> Additional testing:
> - [x] MacOS AArch64 server fastdebug *gtets*
> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
> - [ ] Benchmarking
> 
> @apangin and @parttimenerd could you please check the patch on your 
> scenarios??

I think there is a sweet-spot middle-ground between the two extremes: 
full-lazy, ideal for performance, and fine-grained execute-by-default, ideal 
for security.  I don't think we should change to full-lazy and remove all the 
guard rails at this time.  I am investigating execute-by-default, and it looks 
promising.

-

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18762#pullrequestreview-2051465621

Re: E-comm live project

2024-05-06 Thread Dean Mahori

Add me
+263786881635

Sent from Outlook for Android

From: django-users@googlegroups.com  on behalf 
of amruth bitla 
Sent: Monday, May 6, 2024 6:23:52 PM
To: Django users 
Subject: Re: E-comm live project

Hi  1001_prabhjot Singh,

I am interested, check out my GitHuB Page for Django 
Project, Please Email me.

On Monday, May 6, 2024 at 12:13:13 PM UTC-4 avdesh sharma wrote:
I am interested, +91-9650031844

On Mon, Mar 18, 2024 at 10:56 PM 1001_prabhjot Singh  
wrote:
so i am working on a full stack e-comm website and this project is really very 
big for me because it's a live project am using django for backend interested 
one's can send there number for WhatsApp group

--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1101d563-726a-458e-ad9f-4b91bebf3132n%40googlegroups.com.


--
Warm Regards,
Avdesh Kumar Sharma
9650031844

--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a84f1fdf-36de-4a79-b628-b2a50c576f3an%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/PAXP193MB2202C8F3EC53FC22B974B0D0FF1C2%40PAXP193MB2202.EURP193.PROD.OUTLOOK.COM.

Dear Programmers,
My name is Dean Mahori and I'm a student at Chinhoyi University . I'm
working on a university project to build a website using the Django
framework.
I'm currently in the process of developing a website to better connect with
our community and raise awareness about our cause. While I'm excited to
embark on this project, I'm also new to website development and could
really use some assistance.
I'm particularly interested in using Django, a Python web framework, to
build the website. I've been doing some research on it and believe it
would be a good fit for our needs. However, as a beginner, I would greatly
appreciate any guidance or support from experienced Django programmers. I'm
also open to different approaches and suggestions from experienced
programmers.

Here are some specific areas where I could use help:

Project Setup and Best Practices: Ensuring a solid foundation for the
website's development.
Understanding Django Features: Learning how to effectively utilize
Django functionalities for our website.
Building Core functionalities: Developing essential features like user
registration, content management, and potentially donation options.

I understand that volunteering your time is valuable, and I'm incredibly
grateful for any assistance you can offer. Even if it's just pointing me
in the right direction with resources or tutorials, it would be immensely
helpful.
I'm happy to discuss the project further and answer any questions you may
have. Please feel free to contact me at deanmah...@gmail.com or
+263786881635
You can also comment with your whatsapp number so that i can create a group
for all of us.

Thank you for your time and consideration.

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAOxCe%3DSQMWYKQzf4ODUVqEXqmZB%2BN1R%3DWvbZLNzxAzPa6F7k7A%40mail.gmail.com.

Re: E-comm live project

2024-05-04 Thread Dean Mahori

add me +263786881635


On Tue, Apr 30, 2024 at 3:23 PM Kintu Peter  wrote:

> Watsap +256789746493
>
>
> On Monday, March 18, 2024 at 8:26:50 PM UTC+3 1001_prabhjot Singh wrote:
>
>> so i am working on a full stack e-comm website and this project is really
>> very big for me because it's a live project am using django for backend
>> interested one's can send there number for WhatsApp group
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/133bfa88-4044-4bdc-9602-9c3a5ec276b7n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAOxCe%3DS22%3DXqpQOP9gPAqTR4%2B1xHhMNoCacMMOsMPNa7Kvuhbw%40mail.gmail.com.

[Cscwg-public] CSCWG April 18, 2024 Final meeting minutes

2024-05-02 Thread Dean Coclin via Cscwg-public

 

2024-04-18 Final Minutes

 

Attendees:

Andrea Holland (VikingCloud), Ben Dewberry (Keyfactor), Brian Winters
(IdenTrust), Bruce Morton (Entrust), Christophe Bonjean (GlobalSign), Corey
Bonnell (DigiCert), Dean Coclin (DigiCert), Dimitris Zacharopoulos (HARICA),
Eva Vansteenberge (GlobalSign), Inaba Atsushi (GlobalSign), Inigo Barreira
(Sectigo), Janet Hines (VikingCloud), Marco Schambach (IdenTrust), Martijn
Katerbarg (Sectigo), Nome Huang (TrustAsia), Scott Rea (eMudhra), Thomas
Zermeno (SSL.com), Tim Crawford (CPA Canada/WebTrust), Wangmo Tenzing
(Wangmo Tenzing)

 

Minute-taker: Corey Bonnell

 

Bruce read the note well.

 

Bruce said he will call for approval of the F2F minutes at the next meeting.

 

Meeting minutes for the March 21st meeting were approved.

Meeting minutes for the April 4th meeting were approved.

 

* Obsolete EVCS guidelines

 

Dimitris said the ballot needs to be converted to PDF and circulated on the
mailing list.

Bruce said he will take care of that and Corey will publish on the website.

 

* Remove EVG references

 

Dimitris asked for a review of this draft ballot. He said that a mapping
document is

available to assist in the review. Martijn and Corey offered to review the
PR

(https://url.avanan.click/v2/___https://github.com/cabforum/code-signing/pul
l/38___.YXAzOmRpZ2ljZXJ0OmE6bzo2Yjk1MjA2NDAyYWY4YmM5MzU3OGI3ODRkNWY2ZGQ3NDo2
OmNiMGU6ZDEzMDg3NzRjMzc5ZDE4YjE5MTZjNDY2ODNhODgxNjIxYTY0OTY4MGMxNDc0MzJmOGRh
ZTMxNWYwOWM0NjkzOTp0OkY
<https://url.avanan.click/v2/___https:/github.com/cabforum/code-signing/pull
/38___.YXAzOmRpZ2ljZXJ0OmE6bzo2Yjk1MjA2NDAyYWY4YmM5MzU3OGI3ODRkNWY2ZGQ3NDo2O
mNiMGU6ZDEzMDg3NzRjMzc5ZDE4YjE5MTZjNDY2ODNhODgxNjIxYTY0OTY4MGMxNDc0MzJmOGRhZ
TMxNWYwOWM0NjkzOTp0OkY> ).

 

* Change to timestamp requirements

 

Martijn said Christophe provided several comments on the PR. Christophe
raised a

concern that re-issuance of a timestamping ICA would incur the requirement
to move

the CA private key to offline HSM. Bruce also raised a concern that
long-lived

timestamping CAs could be stored in online HSMs despite this ballot. Martijn

said that we could create an effective date to require CAs to move to
offline HSMs,

but that may be complex.

 

Dimitris said that moving a key does not eliminate the risk, as it was
previously

stored in an online HSM. Additionally, keys could have been generated before
the

effective date in an online state prior to being certified in a certificate.

Martijn said that if a key has been generated online, then it couldn't be
said that

it was "maintained" in an offline state. Martijn said he can clarify this in
the ballot.

 

Martijn said to resolve the concern about legacy online CAs being used in
perpetuity,

that we could propose a sunset date for issuing end-entity timestamping
responder

certificates to force a rotation to offline CA keys. Corey agreed with that
approach.

 

* Other business

 

Martijn said a ballot for modifying logging requirements in the TLS BRs.
He'd like

to align the CS BRs with this language. He will write a ballot to do this
and will

call for endorsers.

 

Martijn also mentioned that we could remove the EVCS JOI fields and replace
with

the orgId, as is done in the SMBRs, but said it might be too early for that
change.

Bruce said we should reconsider all subject fields in light of the
deprecation of

EV CS. Dimitris agreed and said that we need to incorporate Microsoft's
plans

on the validation level of code signing certificates.

 

Next meeting is May 2nd. Meeting adjourned.



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

[Cscwg-public] Final minutes of F2F CSCWG Feb 28, 2024

2024-05-02 Thread Dean Coclin via Cscwg-public

 

Code Signing Certificate Working Group Draft Minutes Feb 28, 2024 F2F
Meeting India

 

Discussion leader: Bruce Morton (Entrust)

Minutes: Andrea Holland (VikingCloud)

 

Attendees: Paul van Brouwershaven (Entrust), Dustin Hollenback (Microsoft),
Tim Callan (Sectigo), Scott Rea (eMudhra), Dimitris Zacharopoulos (HARICA),
Arno Fiedler (ETSI), Arvid Vermote (GlobalSign), Ashish Dhiman (GlobalSign),
Tadahiko Ito (SECOM), Corey Bonnell (DigiCert), Inigo Barreira (Sectigo),
Mrugesh Chandarana (IdenTrust), Marco Schambach (IdenTrust), Nitesh Bakliwal
(Microsoft), Kiran AM (eMudhra), Keshava N (eMudhra), Abhishek Bhat
(eMudhra), Naveen Kumar (eMudhra), Yashwanth (eMudhra), Dean Coclin
(DigiCert), Thomas Zermeno (SSL.com), Mohit Kumar (GlobalSign), Martijn
Katerbarg (Sectigo), Nargis Mannan (Viking Cloud), Marco Schambach
(IdenTrust), Tim Hollebeek (DigiCert), Atsushi Inaba (GlobalSign), Trevoli
Ponds-White (Amazon Trust Services), Aaron Poulsen (Amazon Trust Services),
Rich Smith (DigiCert), Roman Fischer (SwissSign), Eva Van Steenberge
(GlobalSign), Rollin Yu (TrustAsia), Michael Slaughter (Amazon Trust
Services), Nome Huang (TrustAsia), Kateryna Aleksieieva (Certum), Andrea
Holland (VikingCloud), Bruce Morton (Entrust), Tim Crawford (CPA
Canada/WebTrust), Ian McMillan (Microsoft), Stefan Kirch (Telekom Security),
Tsung-Min Kuo (Chunghwa Telecom), Rebecca Kelley (Apple), Li-Chun Chen
(Chunghwa Telecom)Interested Party: Ben Wilson (Mozilla), Invited Guests:
Ramachandran P (Office of CCA, MEITY, Govt of India), Mike Kushner
(Keyfactor), Seven Rajala (Keyfactor), 

 

Detailed minutes:

 

1.  Antitrust Compliance Statement read

2.  Review Agenda

3.  Statement from Nitish. 

*   Survey went out from Microsoft. If you have not received it please
reach out. 

*   Update to EV CS OID changes.

*   Deadline of August 2024 for feedback and reasons/scenarios for
supporting.

*   Timeline of February 2025 of planned removal of support of EV Code
Signing.

*   Policy update of removal of EV CS OID was published early and will
be reverted until the planned removal date.

*   Clarification that OCSP is required only for TLS not for Code
Signing or S/MIME.

4.  Approval of February 8th minutes
5.  Certificate Transparency for Code Signing

*   Discussion by Ian, Trev, Tim H., Bruce, Dimitris, Martijn, Paul, and
Dean.

*   Discussion about the problem statement for the need of public
transparency for Code Signing certificates and the revocation aspect.

*   Discussion on the infrastructure of the tools necessary to monitor
the CT logs as well as subscriber benefits, but these should be a secondary
phase.

*   Discussion around use case of CT for CS and the differences between
CT for TLS vs for CS. 

*   Code Signing certificates are signing code that can last forever
which impacts the length of time needed for the CT log.

*   Single use CS certificates would cause a high number of records on
the CT logs.

*   Specific questions were discussed: How long should a record be in a
Trusted CT Log? What happens when a log gets retired? How long should a log
be active? How many logs would CAs be required to log to? These will be
continued based on implementation.

*   Action item: To define/refine the problem statement. 

6.  Reduction of Code Signing validity to 15 months

*   Discussion by Ian, Bruce, Dean, Martijn, Tim C., Dimitris, and Trev

*   Reason for request is the longer a validity period causes a
revocation to have a larger impact radius which causes unintended collateral
damage.

*   Original time of 39 months was based on the common actions at the
time, should this be revisited. How many certificates are being issued at 39
months? Are 12 month certs more common, or has this changed due to the
protection of the private key requirement? 

*   Discussion that the worry is the amount of software that is signed
under a particular key. In the event that a key gets compromised, you have
to revoke a whole bunch of software.

*   Action item: Get the data, review, and move forward from there.

7.  Ballot for EVG import

*   Discussion by Bruce, Tim H., Ian, Tim C., Dimitris, Mrugesh, Trev,
Enrico, and Paul

*   The idea is that non-EV code signing is going away and EV will be
the new standard. 

*   Microsoft confirms that hardware dev center is the only remaining
location which policy says EV cert is needed for onboarding only. Smart
screen doesn't distinguish between the two. 

*   Microsoft doesn't differentiate between OV and EV OIDs they are
treated the same.

*   Microsoft wants to simplify to one type of CS certificate with the
only difference in validation type (individual validation vs organization
validation). 

*   CS BRs points to specific references in EV Guidelines. The EVG
import should be completed first. Then next step is to simply CS BRs to
match with one CS type. The goal

[Cscwg-public] CSCWG Agenda May 2, 2024

2024-04-30 Thread Dean Coclin via Cscwg-public

 

MINUTE TAKER: NEED A VOLUNTEER, START RECORDING

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (Andrea), April 18th (Corey)
4.  Proposed ballots: Remove EV Guideline References
5.  Proposed ballot for Time-stamp Requirements update; CSC-24
6.  Discuss F2F Agenda
7.  Other business
8.  Next meeting - May 16th   
9.  Adjourn

 

 

Dean Coclin 

CSCWG Chair

 

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]

2024-04-29 Thread Dean Long

On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov  wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes 
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
>> speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
>> nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
>> nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Address comments. Moved jvmci_data back to mutable data section.

Marked as reviewed by dlong (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/18984#pullrequestreview-2027786061

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

2024-04-29 Thread Dean Long

On Sun, 28 Apr 2024 07:02:40 GMT, Dean Long  wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes 
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
>> speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
>> nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
>> nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> It only makes sense if the immutable data heap is not also used for other 
> critical resources.  If malloc or metaspace were used as the immutable data 
> heap, normally failures in those heaps are fatal, because other critical 
> resources (monitors, classes, etc) are allocated from there, so any failure 
> means the JVM is about to die.  There's no reason to find a fall-back method 
> to allocate a new nmethod in that case.

> Just to be clear @dean-long , you're saying failure to allocate immutable 
> data in the C heap should result in a fatal error? Makes sense to me as the 
> VM must indeed be very close to crashing anyway in that case. It also, 
> obviates the need for propagating `out_of_memory_error` to JVMCI code.

I hadn't thought it through that far, actually.  I was only pointing out that 
the proposed fall-back:

> increase nmethod size and put immutable data there (as before).

isn't worth the trouble.  But making the C heap failure fatal immediately is 
reasonable, especially if it simplifies JVMCI error reporting.

-

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2082083104

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

2024-04-28 Thread Dean Long

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

It only makes sense if the immutable data heap is not also used for other 
critical resources.  If malloc or metaspace were used as the immutable data 
heap, normally failures in those heaps are fatal, because other critical 
resources (monitors, classes, etc) are allocated from there, so any failure 
means the JVM is about to die.  There's no reason to find a fall-back method to 
allocate a new nmethod in that case.

-

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2081364009

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 528:

> 526:   private int getScopesDataOffset()   { return (int) 
> scopesDataOffsetField  .getValue(addr); }
> 527:   private int getScopesPCsOffset(){ return (int) 
> scopesPCsOffsetField   .getValue(addr); }
> 528:   private int getDependenciesOffset() { return (int) 0; }

Suggestion:


No longer used.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581671710

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/code/nmethod.cpp line 1484:

> 1482:   // Calculate positive offset as distance between the start of 
> stubs section
> 1483:   // (which is also the end of instructions section) and the start 
> of the handler.
> 1484:   CHECKED_CAST(_unwind_handler_offset, int16_t, (_stub_offset - 
> code_offset() - offsets->value(CodeOffsets::UnwindHandler)));

Suggestion:

  int unwind_handler_offset = code_offset() + 
offsets->value(CodeOffsets::UnwindHandler);
  CHECKED_CAST(_unwind_handler_offset, int16_t, _stub_offset - 
unwind_handler_offset);

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581644356

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/code/nmethod.cpp line 1332:

> 1330: #if INCLUDE_JVMCI
> 1331: _speculations_offset = _scopes_data_offset;
> 1332: _jvmci_data_offset   = _speculations_offset;

Why not use 0 for all these?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581642931

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

On Fri, 26 Apr 2024 21:36:50 GMT, Vladimir Kozlov  wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes 
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
>> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
>> in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
>> nmethod's data. Bail out compilation if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
>> nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> src/hotspot/share/code/nmethod.cpp line 117:
> 
>> 115:   result = static_cast(thing); \
>> 116:   assert(static_cast(result) == thing, "failed: %d != %d", 
>> static_cast(result), thing);
>> 117: 
> 
> I replaced `checked_cast<>()` with this macro because of next issues:
>  - The existing assert points to `utilities/checkedCast.hpp` file where this 
> method is located and not where failed cast. It does not help when it is used 
> several times in one method (for example, in `nmethod()` constructors).
>  - The existing assert does not print values

I thought @kimbarrett had a draft PR to address the error reporting issue, but 
I can't seem to find it.  To solve the general problem, I think we need a 
version of vmassert() that takes `char* file, int lineno` as arguments, and a 
macro wrapper for checked_cast() that passes `__FILE__` and `__LINEN__` from 
the caller.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581628786

[ccp4bb] Postdoctoral Research Associate – Biochemistry/Biophysics

2024-04-25 Thread Myles, Dean A A

The Diffraction Group in the Neutron Scattering Division (NSD) at Oak Ridge 
National Laboratory (ORNL) has an immediate opening for a postdoctoral 
Biochemist or Biophysicist to join a multi-disciplinary research team in 
development and application of paramagnetic labeling and proton polarization 
techniques for structure analysis. This project involves multi-task efforts in 
molecular biology, NMR, dynamic nuclear polarization (DNP) and macromolecular 
crystallography, and collaboration with computational scientists developing ML 
and AI tools for molecular simulation and analysis. As an ORNL postdoctoral 
fellow you will have access to state-of-the-art facilities for isotopic 
labeling, biophysical characterization and X-ray diffraction, as well as access 
to world class facilities for neutron diffraction and scattering, and molecular 
simulations. The position represents an excellent opportunity for you to 
develop your career and interact with leading scientists from around the world.

A link to the position advertisement can be found here:

https://jobs.ornl.gov/job/Oak-Ridge-Postdoctoral-Research-Associate-Structural-Biology%2C-Biochemistry-and-Biophysics-TN-37830/1155718000/




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[tarlz] testsuite failure on Alpine (edge)

2024-04-24 Thread J Dean

0.25 against lzlib 1.14 and/or 1.15-pre1. dynamic and static builds all fail at 
the same point: 

g++ -march=native -O2 -fstack-protector-strong -fstack-clash-protection 
-ftrivial-auto-var-init=zero -fcf-protection=full -mshstk -Wformat 
-Werror=format-security -fomit-frame-pointer -flto=auto -ffat-lto-objects -pipe 
-D_GLIBCXX_ASSERTIONS=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 
-D_LIBCPP_ENABLE_HARDENED_MODE=1 -static-pie 
-Wl,-z,relro,-z,now,-z,pack-relative-relocs -o tarlz arg_parser.o lzip_index.o 
archive_reader.o common.o common_decode.o common_mutex.o compress.o create.o 
create_lz.o decode.o decode_lz.o delete.o delete_lz.o exclude.o extended.o 
main.o -llz -lpthread
testing tarlz-0.25...
testing --list and --extract...
testing --concatenate...
testing --create...touch: invalid date '2022-01-05T12:22:13'
failure in testing framework
make: *** [Makefile:95: check] Error 1
>>> ERROR: tarlz: check failed

could this be a busybox touch quirk? only by patching the --create --mtime test 
section out does the build complete with all other tests passing. 

--- /dev/null
+++ b/testsuite/check.sh
@@ -731,35 +731,6 @@
 [ ! -e baz ] || test_failed $LINENO
 rm -f out.tar foo bar baz || framework_failure
 
-# test --create --mtime
-dates='@-9223372036854775808 @-9223372036854775807
-   -2147481748-12-31T23:59:59 -1970-01-01T00:00:00
-   -01-01T00:00:00 -01-01T00:00:01 -01-02T00:00:00
-   1697-10-17T11:03:27 1697-10-17T11:03:28 1697-10-17T11:03:29
-   1833-11-24T17:31:43 1833-11-24T17:31:44 1833-11-24T17:31:45
-   1901-12-13T20:45:51 1901-12-13T20:45:52 1901-12-13T20:45:53
-   1901-12-14T20:45:51
-   1969-12-31T23:59:58 1969-12-31T23:59:59
-   1970-01-01T00:00:00 1970-01-01T00:00:01 @0
-   2038-01-18T03:14:07 2038-01-19T03:14:07 2038-01-19T03:14:08
-   2106-02-07T06:28:15 2106-02-07T06:28:16
-   2242-03-16T12:56:31 2242-03-16T12:56:32 @8589934591 @8589934592
-   -12-31T23:59:58 -12-31T23:59:59
-   2147483647-12-31T23:59:59 @9223372036854775807'
-touch -d 2022-01-05T12:22:13 bar || framework_failure
-for i in ${dates} @-8Ei '2017-10-01 09:00:00' '2017-10-1 9:0:0' \
- '2017-10-01 09:00' '2017-10-01 09' 2017-10-01 ./bar ; do
-  touch foo || framework_failure
-  "${TARLZ}" -cf out.tar --mtime="$i" foo || test_failed $LINENO "$i"
-  is_uncompressed out.tar || test_failed $LINENO "$i"
-  "${TARLZ}" -q -df out.tar && test_failed $LINENO "$i"
-  "${TARLZ}" -xf out.tar || test_failed $LINENO "$i"
-  if [ "${d_works}" = yes ] ; then
-"${TARLZ}" -df out.tar --ignore-overflow || test_failed $LINENO "$i"
-  fi
-done
-rm -f out.tar foo bar || framework_failure
-
 mkdir dir || framework_failure
 for i in ${dates} ; do
   # Skip a time stamp $i if it's out of range for this platform,

would like to package this for Alpine (lzip/lzlib/plzip are already in the 
official repos). is there a workaround, perhaps an alternative test? or can the 
test be patched out as above and the resultant binary be used in production, 
despite the check failure?

Re: RPi 4b Wifi Device

2024-04-23 Thread Thomas D. Dean


On 4/23/24 08:54, Justin Parrott wrote:

this is what i was talking about, i don't like booting an sbc from stick

even if you can hit disk

can net run on sbc?



I can boot NetBSD 10 on an RPi 4b from an SD card . It seems to run 
fine. Seems lots faster than RPi OS booted from the same type SD card.


I can
  1. access the network
  2. ssh into the RPi
  3. build applications
on a RPi 4B running NetBSD 10 booted from an SD card.

What I can not do is get the RPi 4b to boot NetBSD from a USB-3 flash drive.

I can get the RPi 4b to boot RPi OS from the USB-3 flask drive.

Tom Dean

Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

2024-04-23 Thread Saxe, Dean

Thanks Pieter!
-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com<mailto:deans...@amazon.com> | M: 
206-659-7293

From: Pieter Kasselman 
Date: Tuesday, April 23, 2024 at 7:02 AM
To: "Saxe, Dean" , "rifaat.s.ietf" 
, oauth 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi Dean, thanks for taking the time to review and provide feedback Dean, much 
appreciated.

I have opened issues to address each of the items highlighted.


  1.  Add verbiage to diagrams: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/124
  2.  Make examples consistent for Section 3.1.3: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/125
  3.  Clarify origin of QR Code: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/126
  4.  Editorial updates: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/127
  5.  FIDO Reference update: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/128
  6.  Update Guidance on using FIDO: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/129

Cheers

Pieter


From: OAuth  On Behalf Of Saxe, Dean
Sent: Monday, April 22, 2024 6:54 PM
To: rifaat.s.ietf ; oauth 
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP


You don't often get email from 
deansaxe=40amazon@dmarc.ietf.org<mailto:deansaxe=40amazon@dmarc.ietf.org>.
 Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Rifaat,

I have a few minor nits in the doc, nothing of significant concern for WGLC.


  1.  When describing the visuals documenting the flows, there is a step that 
includes “The user authenticates to the authorization server”.  In each case 
this should include verbiage to indicate that this is only necessary if the 
user is unauthenticated, e.g. “If unauthenticated, the user authenticates to 
the authorization server…”.  Specific sections include 3.1.1, 3.1.2, 4.1.1, 
4.1.2
  2.  Section 3.1.3 the final sentence notes the authorization data may be 
delivered as a text message or via a mobile app.  This is inconsistent with the 
methods mentioned in the first paragraph, which includes email and text 
messages.  I suggest being clear that these are example mechanisms and not a 
full list of mechanisms by which codes can be delivered.
  3.  Section 3.3.1 the first sentence should note that the QR code is 
associated with the particular service (Netflix, AppleTV, Disney+).  Readers 
could assume that the QR codes originate from the TV manufacturer’s service 
alone as written.
  4.  Section 4.3.9 reads, “… using an e-mail campaign etc.”  Should this be 
rewritten, “using an e-mail campaign, for example.”?
  5.  Section 6.2.3 discusses FIDO CTAP 2.2.  This document is still in review 
draft 01<https://fidoalliance.org/specifications/download/>.  We should note 
that the document is not final as of today.
  6.  Section 6.2.3.5 could be softened a bit.  The first sentence should 
include, “… and a suitable FIDO credential is not available on the consumption 
device.”  In most patterns, this mechanism is used to bootstrap a new 
credential on the device, rather than using this mechanism for authN every time.

Authors, if you have any questions please let me know.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com<mailto:deans...@amazon.com> | M: 
206-659-7293

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>>
Date: Monday, April 22, 2024 at 7:57 AM
To: oauth mailto:oauth@ietf.org>>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: RPi 4b Wifi Device

2024-04-23 Thread Thomas D. Dean

On 4/20/24 15:29, Michael Cheponis wrote:
> I run an RPi 4B/8G with external USB SSD drive; I do this because my 
uSD cards were getting worn out after about a year of use; I've had no 
such problems with my Samsung 870 EVO nor Samsung SSD T7.

>
> I use the built-in GigE adaptor on the RPi 4B, because it's 
convenient as I have wired ethernet most places.   So I can't help with 
WiFi.

>
> I have been running an RPi 3 from a Lexar 64B Thumb Drive since June 
2019 - no problem there, either.

I use SanDisk Extreme Pro 128GiB flash drives in the RPi 4b USB 3 port, 
sometimes with a 6" USB 3 cable.

I can always boot RPi OS on these drives. I have never been able to boot 
NetBSD 10.

I downloaded the arm64.img, and RPi4_UEFI_Firmware_v1.35.zip. On a Linux 
desktop:

  dd if=arm64.img of=/dev/sda bs=1M
and, then I replace the corresponding files from 
RPi4_UEFI_Firmware_v1.35.zip.

  mount /de3v/sda1 /mnt
  cd /mnt
  unzip ~/NetBSD/RPi4_UEFI_Firmware_v1.35.zip

When I attempt to boot, I see the color flash, then a cursor at the top 
left of the screen, then the screen goes blank.

he flash drive shows lots of accesses during this process and then shows 
access flashes in groups of 3 or 4. I think this indicates an unreadable 
file, I think.

When I do the the same actions with an SD card, NetBSD boots.

What do you do?

Tom Dean

Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

2024-04-22 Thread Saxe, Dean

Rifaat,

I have a few minor nits in the doc, nothing of significant concern for WGLC.


  1.  When describing the visuals documenting the flows, there is a step that 
includes “The user authenticates to the authorization server”.  In each case 
this should include verbiage to indicate that this is only necessary if the 
user is unauthenticated, e.g. “If unauthenticated, the user authenticates to 
the authorization server…”.  Specific sections include 3.1.1, 3.1.2, 4.1.1, 
4.1.2
  2.  Section 3.1.3 the final sentence notes the authorization data may be 
delivered as a text message or via a mobile app.  This is inconsistent with the 
methods mentioned in the first paragraph, which includes email and text 
messages.  I suggest being clear that these are example mechanisms and not a 
full list of mechanisms by which codes can be delivered.
  3.  Section 3.3.1 the first sentence should note that the QR code is 
associated with the particular service (Netflix, AppleTV, Disney+).  Readers 
could assume that the QR codes originate from the TV manufacturer’s service 
alone as written.
  4.  Section 4.3.9 reads, “… using an e-mail campaign etc.”  Should this be 
rewritten, “using an e-mail campaign, for example.”?
  5.  Section 6.2.3 discusses FIDO CTAP 2.2.  This document is still in review 
draft 01<https://fidoalliance.org/specifications/download/>.  We should note 
that the document is not final as of today.
  6.  Section 6.2.3.5 could be softened a bit.  The first sentence should 
include, “… and a suitable FIDO credential is not available on the consumption 
device.”  In most patterns, this mechanism is used to bootstrap a new 
credential on the device, rather than using this mechanism for authN every time.

Authors, if you have any questions please let me know.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com<mailto:deans...@amazon.com> | M: 
206-659-7293

From: OAuth  on behalf of Rifaat Shekh-Yusef 

Date: Monday, April 22, 2024 at 7:57 AM
To: oauth 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

2024-04-22 Thread Dean Rasheed

On Mon, 22 Apr 2024 at 06:04, Michael Paquier  wrote:
>
> On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
>
> I don't see why not for the places you are changing here, we can be
> more consistent.

[Shrug] I do prefer using a macro. Adding a counter element to the end
of the enum feels like a hack, because the counter isn't the same kind
of thing as all the other enum elements, so it feels out of place in
the enum. On the other hand, I think it's a fairly common pattern that
most people will recognise, and for other enums that are more likely
to grow over time, it might be less error-prone than a macro, which
people might overlook and fail to update.

>  Now, such changes are material for v18.

Agreed. This has been added to the next commitfest, so let's see what
others think.

Regards,
Dean

NetBSD RPi 4b Install/Boot Failure

I am using a SanDisk Extreme Pro 128GiB flash drive connected to the RPi 
4b USB-3 port.


I can use this with the RPi OS.

I tried downloading Generic 64-bit from 
http://nycdn.netbsd.org/pub/arm/, marked as for the Raspberry Pi. I 
unzipped the file to get the .img.




> ls -l NetBSD-10-aarch64--generic.img
-rw-rw-r-- 1 tomdean tomdean 1582301184 Apr 20 20:46 
NetBSD-10-aarch64--generic.img


> sudo dd if=NetBSD-10-aarch64--generic.img of=/dev/sda bs=1M conv=sync
1509+0 records in
1509+0 records out
1582301184 bytes (1.6 GB, 1.5 GiB) copied, 6.21875 s, 254 MB/s

> sudo mount /dev/sda1 /mnt
> ls /mnt
EFI   cmdline.txt  fixup.dat fixup_cd.dat  start4.elf
LICENCE.broadcom  config.txt   fixup4.datnetbsd.imgstart4cd.elf
bootcode.bin  dtb  fixup4cd.dat  start.elf start_cd.elf

> cat /mnt/cmdline.txt
root=NAME=netbsd-root console=fb

> cat /mnt/config.txt
#
upstream_kernel=1
#
arm_64bit=1
os_prefix=dtb/broadcom/
cmdline=../../cmdline.txt
kernel=/netbsd.img
kernel_address=0x20
enable_uart=1
force_turbo=0

I connected a HDMI display and the SanDisk Extreme Pro flash drive (USB 
3) to the RPi 4b and applied power.


The led on the flash drive blinked for 3~4 seconds and stopped. The 
screen flashed and went blank. Nothing afterwards...


I booted the RPi 4b from a SD card, NetBSD 10 and connected the flash 
drive to a USB-3 port.


fsck says the drive is OK.

I mounted /dev/dk2 on /mnt There are some missing files on dk2 as 
compared to /boot.


pi-4b-1# ls -l /mnt
total 23142
drwxr-xr-x  1 root  wheel  1024 Mar 28 16:53 EFI
-rwxr-xr-x  1 root  wheel  1594 Mar 28 16:53 LICENCE.broadcom
-rwxr-xr-x  1 root  wheel 52476 Mar 28 16:53 bootcode.bin
-rwxr-xr-x  1 root  wheel33 Mar 28 16:53 cmdline.txt
-rwxr-xr-x  1 root  wheel   155 Mar 28 16:53 config.txt
drwxr-xr-x  1 root  wheel  1024 Mar 28 16:53 dtb
-rwxr-xr-x  1 root  wheel  7269 Mar 28 16:53 fixup.dat
-rwxr-xr-x  1 root  wheel  5412 Mar 28 16:53 fixup4.dat
-rwxr-xr-x  1 root  wheel  3180 Mar 28 16:53 fixup4cd.dat
-rwxr-xr-x  1 root  wheel  3180 Mar 28 16:53 fixup_cd.dat
-rwxr-xr-x  1 root  wheel  16761568 Mar 28 16:53 netbsd.img
-rwxr-xr-x  1 root  wheel   2979264 Mar 28 16:53 start.elf
-rwxr-xr-x  1 root  wheel   2254944 Mar 28 16:53 start4.elf
-rwxr-xr-x  1 root  wheel808060 Mar 28 16:53 start4cd.elf
-rwxr-xr-x  1 root  wheel808060 Mar 28 16:53 start_cd.elf
rpi-4b-1# ls -l /boot
total 25293
drwxr-xr-x  1 root  wheel  1024 Apr  1 22:28 EFI
-rwxr-xr-x  1 root  wheel  1594 Apr  1 22:28 LICENCE.broadcom
-rwxr-xr-x  1 root  wheel   2031616 Jun  5  2023 RPI_EFI.fd
-rwxr-xr-x  1 root  wheel  5051 Jun  5  2023 Readme.md
-rwxr-xr-x  1 root  wheel 54388 Jun  5  2023 bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root  wheel 54477 Jun  5  2023 bcm2711-rpi-400.dtb
-rwxr-xr-x  1 root  wheel 54997 Jun  5  2023 bcm2711-rpi-cm4.dtb
-rwxr-xr-x  1 root  wheel 52476 Apr  1 22:28 bootcode.bin
-rwxr-xr-x  1 root  wheel33 Apr  1 22:28 cmdline.txt
-rwxr-xr-x  1 root  wheel   243 Jun  5  2023 config.txt
drwxr-xr-x  1 root  wheel  1024 Apr  1 22:28 dtb
drwxr-xr-x  1 root  wheel  1024 Apr 19 04:13 firmware
-rwxr-xr-x  1 root  wheel  7269 Apr  1 22:28 fixup.dat
-rwxr-xr-x  1 root  wheel  5397 Jun  5  2023 fixup4.dat
-rwxr-xr-x  1 root  wheel  3180 Apr  1 22:28 fixup4cd.dat
-rwxr-xr-x  1 root  wheel  3180 Apr  1 22:28 fixup_cd.dat
-rwxr-xr-x  1 root  wheel  16761568 Apr  1 22:28 netbsd.img
drwxr-xr-x  1 root  wheel  1024 Apr 19 04:13 overlays
-rwxr-xr-x  1 root  wheel   2979264 Apr  1 22:28 start.elf
-rwxr-xr-x  1 root  wheel   2253088 Jun  5  2023 start4.elf
-rwxr-xr-x  1 root  wheel808060 Apr  1 22:28 start4cd.elf
-rwxr-xr-x  1 root  wheel808060 Apr  1 22:28 start_cd.elf

Any ideas?

Tom Dean

Re: need your advice before new Raspberry Pi purchase


On 4/20/24 17:24, Michael wrote:

The 3GB limit is on by default for some old linux kernels that don't
have the DMA workaround. It takes about 10 seconds to get into the UEFI
setup menu and turn it off.


What is the UEFI setup menu? How do I get in to it?

I used dd to write arm64.img to the USB 3 flash drive.

Is the NetBSD installer available in the arm64.img? Is it possible to 
use the installer on the RPi 4b (booted from the SD card) to install 
NetBSD 10 on the USB 3 flash drive?


Tom Dean

Re: RPi 4b Wifi Device


On 4/20/24 15:29, Michael Cheponis wrote:
I run an RPi 4B/8G with external USB SSD drive; I do this because my uSD 
cards were getting worn out after about a year of use; I've had no such 
problems with my Samsung 870 EVO nor Samsung SSD T7.


I use the built-in GigE adaptor on the RPi 4B, because it's convenient 
as I have wired ethernet most places.   So I can't help with WiFi.


I have been running an RPi 3 from a Lexar 64B Thumb Drive since June 
2019 - no problem there, either.


I use SanDisk Extreme Pro 128GiB flash drives in the RPi 4b USB 3 port, 
sometimes with a 6" USB 3 cable.


I can always boot RPi OS on these drives. I have never been able to boot 
NetBSD 10.


I downloaded the arm64.img, and RPi4_UEFI_Firmware_v1.35.zip. On a Linux 
desktop:

  dd if=arm64.img of=/dev/sda bs=1M
and, then I replace the corresponding files from 
RPi4_UEFI_Firmware_v1.35.zip.

  mount /de3v/sda1 /mnt
  cd /mnt
  unzip ~/NetBSD/RPi4_UEFI_Firmware_v1.35.zip

When I attempt to boot, I see the color flash, then a cursor at the top 
left of the screen, then the screen goes blank.


The flash drive shows lots of accesses during this process and then 
shows access flashes in groups of 3 or 4. I think this indicates an 
unreadable file, I think.


When I do the the same actions with an SD card, NetBSD boots.

What do you do?

Tom Dean

Re: RPi 4b Wifi Device


On 4/20/24 13:16, Michael van Elst wrote:

tomd...@wavecable.com ("Thomas D. Dean") writes:


# wpa_cli status
Selected interface 'bwfm0'
21:58:44.815: bssid=60:38:e0:db:a9:7a
freq=0
ssid=tddhome
id=0
mode=station
pairwise_cipher=TKIP
group_cipher=TKIP
key_mgmt=WPA-PSK
wpa_state=GROUP_HANDSHAKE
ip_address=169.254.135.120
address=e4:5f:01:da:eb:46



I don't understand where the inet 169.254.135.120 comes from. The router
pool is 192.168.1.xxx.


169.254.x.x is a "link local" address. dhcpcd falls back to such an
address, if it doesn't get an answer from a dhcp server. Apparently
wpa_supplicant cannot connect to the network.


wpa_state=GROUP_HANDSHAKE


says that it still tries to associate. When it's done this would
change to COMPLETED.



I have two RPi 4b's. One with NetBSD 10 on an SD card and the other with 
RPi OS on a USB flash drive. (I can not get NetBSD to boot from a flash 
drive)


As far as I can tell the network configurations are the same for WIFI on 
both. I see comments on the web about NetBSD 10 problems with the bwfm 
device.


I need WIFI. So, I go back to RPi OS.

Thanks for all the replies.

Tom Dean

Re: RPi 4b Wifi Device


I have Authentication timeout.

# wpa_cli
> scan_results
23:27:43.451: bssid / frequency / signal level / flags / 
ssid60:38:e0:db:a9:7a	2462	227	[WPA-PSK-TKIP][ESS]	tddhome

...
 23:27:47.736: CTRL-EVENT-SCAN-RESULTS
  23:27:47.736: Trying to associate with 60:38:e0:db:a9:7a 
(SSID='tddhome' freq=2462 MHz)

  23:27:52.874: Associated with 60:38:e0:db:a9:7a
  23:28:02.888: Authentication with 60:38:e0:db:a9:7a timed out.
  23:28:02.889: CTRL-EVENT-DISCONNECTED bssid=60:38:e0:db:a9:7a 
reason=3 locally_generated=1
  23:28:02.889: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="tddhome" 
auth_failures=1 duration=10 reason=CONN_FAILED


The linksys router uses WPA2/WPA mixed Personal. PSK is correct in 
etc/wpa_supplicant.conf:


# cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
ssid="tddhome"
key_mgmt=WPA-PSK
    psk="..."
}

Tom Dean

Re: RPi 4b Wifi Device


On 4/19/24 18:35, Michael van Elst wrote:

tomd...@wavecable.com ("Thomas D. Dean") writes:


How do I setup wpa_supplicant?


That depends on what you want to do.

Here are some examples:
https://wiki.netbsd.org/tutorials/how_to_use_wpa_supplicant/


I saw that.
dhcp is working over the wired connection.

I thought I had everything configured for wifi. It just does not work.

I have a cable modem <-> wifi/wired router. I have several machines 
connected. Linux and windoze, now. One RPi with NetBSD 10. Used to have 
some FreeBSD machines, but, they have been replaced.


# etc/rc.d/wpa_supplicant reload
Selected interface 'bwfm0'
21:58:35.931: OK

# wpa_cli status
Selected interface 'bwfm0'
21:58:44.815: bssid=60:38:e0:db:a9:7a
freq=0
ssid=tddhome
id=0
mode=station
pairwise_cipher=TKIP
group_cipher=TKIP
key_mgmt=WPA-PSK
wpa_state=GROUP_HANDSHAKE
ip_address=169.254.135.120
address=e4:5f:01:da:eb:46

# ifconfig bwfm0
bwfm0: flags=0x8843 mtu 1500
ssid "" nwkey 65536:"","","",""
powersave off
address: e4:5f:01:da:eb:46
media: IEEE802.11 autoselect (DS1 mode 11g)
status: no network
inet6 fe80::d7c0:41b9:46a5:a5ff%bwfm0/64 flags 0x8 scopeid 0x3
inet 169.254.135.120/16 broadcast 169.254.255.255 flags 0x4



I don't understand where the inet 169.254.135.120 comes from. The router 
pool is 192.168.1.xxx.


Tom Dean

Re: RPi 4b Wifi Device

2024-04-19 Thread Thomas D. Dean

On 4/19/24 09:40, Michael van Elst wrote:

Reason is that the platform is canonically named "raspberrypi,4-model-b"
but UEFI chose "Raspberry Pi 4 Model B" instead.

> pwd
/home/tomdean/NetBSD
> ls -l
total 2154
-rw-rw-r-- 1 tomdean tomdean  272510976 Apr 18 09:40 
NetBSD-10.0-evbarm-aarch64.iso

drwxrwxr-x 4 tomdean tomdean   4096 Apr 18 21:12 RPi4-1.35
drwxrwxr-x 7 tomdean tomdean   4096 Apr 10 23:27 RPi4-1.37
-rw-rw-r-- 1 tomdean tomdean 433670 Apr 18 16:52 RPi4-1.37.zip
-rw-rw-r-- 1 tomdean tomdean3144359 Apr 18 21:01 
RPi4_UEFI_Firmware_v1.35.zip

-rw-rw-r-- 1 tomdean tomdean 1582301184 Apr  3 15:02 arm64.img
-rw-rw-r-- 1 tomdean tomdean  399419622 Apr 18 09:50 arm64.img.gz

> grep -Rail "raspberrypi\\,4\-model-b" *
RPi4-1.35/bcm2711-rpi-4-b.dtb
arm64.img

> grep -Rail "Raspberry\ Pi\ 4\  Model\  B" *
< nothing found>

I could not get NetBSD 10 to boot with the 1.37 files. With the 1.35 
files, it booted and seems to work, other than WIFI.

I created a link to "Raspberry Pi 4  Model  B" and the error went away.

How do I setup wpa_supplicant?

Tom Dean

Re: RPi 4b Wifi Device

2024-04-19 Thread Thomas D. Dean


On 4/18/24 22:00, Michael van Elst wrote:

tomd...@wavecable.com ("Thomas D. Dean") writes:


What is the wifi device in the RPi 4b? Driver?


It's a chip similar to the one in the older RPIs:

bwfm0: chip 0x4345 rev 6
bwfm0: Firmware file default:brcmfmac43455-sdio.bin
bwfm0: Firmware file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.bin
bwfm0: Found Firmware file: brcmfmac43455-sdio.raspberrypi,4-model-b.bin
bwfm0: NVRAM file default:brcmfmac43455-sdio.txt
bwfm0: NVRAM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.txt
bwfm0: Found NVRAM file: brcmfmac43455-sdio.raspberrypi,4-model-b.txt
bwfm0: CLM file default:brcmfmac43455-sdio.clm_blob
bwfm0: CLM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob
bwfm0: Found CLM file: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob
bwfm0: CHIPACTIVE

bwfm0: flags=0x8843 mtu 1500
 ssid  nwkey *
 powersave off
 bssid ##:##:##:##:##:## chan 100
 address: ##:##:##:##:##:##
 media: IEEE802.11 autoselect (VHT mode 11ac)
 status: active
 inet6 fe80:::::%bwfm0/64 flags 0 scopeid 0x3



I saw bwfm0: in /var/log/messages, from memory, similar to the ones listed.
One error. autoconfiguration error: NVRAM file not available.
The CHIPACTIVE line is missng.

ifconfig does not show bwfm0, only genet0 and lo0.

I managed to get a wired connection (across the room at chin height...)
Networking is up. ntp set the date correctly. DNS works. I can ssh into 
the system.


It has been 5 or 6 years since I ran BSD. I used Berkeley BSD and FreeBSD.

How do I get wifi started? I can start wpa_supplicant and I have a 
network block in /etc/wpa_supplicant.


network={
  ssid=""
  psk=""
}

service wpa_supplicant onestatus shows it is running

Tom Dean

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

2024-04-19 Thread Dean Rasheed

On Thu, 18 Apr 2024 at 13:00, Aleksander Alekseev
 wrote:
>
> Fair point. PFA the alternative version of the patch.
>

Thanks. Committed.

Regards,
Dean

pgsql: Use macro NUM_MERGE_MATCH_KINDS instead of '3' in MERGE code.

2024-04-19 Thread Dean Rasheed

Use macro NUM_MERGE_MATCH_KINDS instead of '3' in MERGE code.

Code quality improvement for 0294df2f1f84.

Aleksander Alekseev, reviewed by Richard Guo.

Discussion: 
https://postgr.es/m/CAJ7c6TMsiaV5urU_Pq6zJ2tXPDwk69-NKVh4AMN5XrRiM7N%2BGA%40mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/2e068db56e31dfb510fe7416e52b7affe26f278f

Modified Files
--
src/backend/optimizer/prep/prepjointree.c | 2 +-
src/backend/parser/parse_merge.c  | 2 +-
src/include/nodes/execnodes.h | 2 +-
src/include/nodes/primnodes.h | 2 ++
4 files changed, 5 insertions(+), 3 deletions(-)

RPi 4b Wifi Device


What is the wifi device in the RPi 4b? Driver?

Tom Dean

Re: Install Failure RPi 4


On 4/18/24 13:56, Thomas D. Dean wrote:


I followed:
https://mail-index.netbsd.org/port-arm/2023/07/19/msg008301.html
and it boots.

download
https://github.com/pftf/RPi4/releases/download/v1.35/RPi4_UEFI_Firmware_v1.35.zip

> mount mmcblk0p1 /mnt
> cd /mnt
> unzip ~/RPi4_UEFI_Firmware_v1.35.zip

and reboot

Tom Dean
Silverdale, WA

Install Failure RPi 4


I have an RPi 4b using a USB flash drive and RPi OS.

I attempted to install NetBSD 10 on an SD card.

On the RPi, I downloaded arm64.img.gz and extracted arm64.img.

> ls -l arm64.img
rw-rw-r-- 1 tomdean tomdean 1582301184 Apr  3 15:02 arm64.img

I used dd to copy the image to an SD card.

> dd if=armv7.img of=/dev/mmcblk0 bs=1m conv=sync

After this, the SD card looked OK for the RPi.

I shut down the RPi, removed the USB flash drive. I connected a mouse, 
keyboard, and display, and powered up with the SD card inserted.


The red LED is on continuously. The green LED flashed for ~1 sec, was 
off for ~1 sec, flashed for ~2 sec, was off for ~2 sec, flashed for ~3 
sec, then was off (5 minutes). The display flashed then was blank, again 
(5 min).


Tom DeanI have an RPi 4b using a USB flash drive and RPi OS.

I attempted to install NetBSD 10 on an SD card.

On the RPi, I downloaded arm64.img.gz and extracted arm64.img.

> ls -l arm64.img
rw-rw-r-- 1 tomdean tomdean 1582301184 Apr  3 15:02 arm64.img

I used dd to copy the image to an SD card.

> dd if=armv7.img of=/dev/mmcblk0 bs=1m conv=sync

After this, the SD card looked OK for the RPi.

I shut down the RPi, removed the USB flash drive. I connected a mouse, 
keyboard, and display, and powered up with the SD card inserted.

The red LED is on continuously. The green LED flashed for ~1 sec, was off for 
~1 sec, flashed for ~2 sec, was off for ~2 sec, flashed for ~3 sec, then was 
off (5 minutes). The display flashed then was blank, again (5 min).

I powered down, removed the SD card, reconnected the USB flash drive and 
powered up. I reinserted the SD card.

> sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 98B95E86-7515-4738-B538-FC5107ADFEC9

Device  Start  End  Sectors  Size Type
/dev/mmcblk0p1  32768   196607   163840   80M EFI System
/dev/mmcblk0p2 196608 62332927 62136320 29.6G NetBSD FFS

> sudo mount /dev/mmcblk0p1 /mnt
> ls -l /mnt
total 23142
drwxr-xr-x 3 root root 1024 Apr  1 23:28 EFI
-rwxr-xr-x 1 root root 1594 Apr  1 23:28 LICENCE.broadcom
-rwxr-xr-x 1 root root52476 Apr  1 23:28 bootcode.bin
-rwxr-xr-x 1 root root   33 Apr  1 23:28 cmdline.txt
-rwxr-xr-x 1 root root  155 Apr  1 23:28 config.txt
drwxr-xr-x 8 root root 1024 Apr  1 23:28 dtb
-rwxr-xr-x 1 root root 7269 Apr  1 23:28 fixup.dat
-rwxr-xr-x 1 root root 5412 Apr  1 23:28 fixup4.dat
-rwxr-xr-x 1 root root 3180 Apr  1 23:28 fixup4cd.dat
-rwxr-xr-x 1 root root 3180 Apr  1 23:28 fixup_cd.dat
-rwxr-xr-x 1 root root 16761568 Apr  1 23:28 netbsd.img
-rwxr-xr-x 1 root root  2979264 Apr  1 23:28 start.elf
-rwxr-xr-x 1 root root  2254944 Apr  1 23:28 start4.elf
-rwxr-xr-x 1 root root   808060 Apr  1 23:28 start4cd.elf
-rwxr-xr-x 1 root root   808060 Apr  1 23:28 start_cd.elf

> cat /mnt/config.txt
#
upstream_kernel=1
#
arm_64bit=1
os_prefix=dtb/broadcom/
cmdline=../../cmdline.txt
kernel=/netbsd.img
kernel_address=0x20
enable_uart=1
force_turbo=0

[Cscwg-public] Final CSCWG Minutes April 4, 2024

2024-04-18 Thread Dean Coclin via Cscwg-public

 

Minutes for CSCWG Call 4 Apr 2024

 

Agenda:

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (awaiting draft from Andrea),
March 21st (Brianca)
4.  Ballot status: Marking the EV CS guidelines obsolete (CSC-23). Do we
need an IPR review?
5.  Proposed ballots: Remove EV Guideline References
6.  Proposed ballot for Time-stamp Requirements update; CSC-24
7.  Continued discussion on Application for Associate Member status from
Keyfactor 
8.  Interested Party application from Wangmo Tenzing (as an individual)
9.  Other business
10. Next meeting - April 18th
11. Adjourn

 

 

Attendees:

Brian Winters (Identrust), Bruce Morton (Entrust), Corey Bonnell (DigiCert),
Dean Coclin (DigiCert), Ian McMillan (Microsoft), Inaba Atsushi
(GlobalSign), Inigo Barreira (Sectigo), Marco Schambach - (IdenTrust), Mohit
Kumar (GlobalSign), Nome Huang - (TrustAsia), Rollin Yu - (TrustAsia), Scott
Rea (eMudhra), Tim Crawford - (CPA Canada/WebTrust), Trevoli Ponds-White -
(Amazon),

 

Minutes:

Dean read the note well.

 

Meeting minutes for F2F-New Delhi (Andrea Holland) yet to be posted.

Meeting minutes for March 21, 2024 Meeting (Brianca Martin) yet to be
posted.

 

Ballot CSC-23 Marking the EV Code Signing Guidelines SUPERCEDED

(Dean) This ballot passed, but the question has arisen whether there is need
for an IPR review since all we are doing is marking these obsolete?

(Bruce) there is nothing to present to lawyers, so what is there to review?

Consensus on call is that IPR Review is not necessary in this case as agreed
in WG call.

 

Removing EVG references in CSBRs

No recent update or status from Dimitris for removing references to EVGs.
Since Dimitris is not on current call, this will be deferred to next
meeting.

 

Ballot CSC-24 Timestamping Private Key Protection

Ballot was posted for discussion on 2 Apr 2024. Bruce raised concern that
potential re-word was required because of NOT catering to Online CAs already
in use. Mohit asked for clarification as to whether this only applied to
future NEW CAs or whether it anticipated existing CAs to also be covered by
the guideline. 

It is expected that some amendments will be applied to address the above,
and a restart to the discussion period will apply.

 

Individual Joiner Request

Wangmo Tenzing from Lawrence Livermore National Lab originally sent IPR
Agreement representing the Lab but clarified that this was rather meant to
be an individual Interested Party and not as the Lab's representative. IPRA
was withdrawn, and request resubmitted as an individual Interested Party.

No objections from WG to accept Wangmo as individual Interested Party. 

 

Associate Member Application

Follow on from previous meeting (and F2F meeting) where discussion was held
regarding Key Factor's application to become an Associated Member. 

No objections from WG to accept Key Factor as Associate Members.

 

Other Business: EV vs OV for Code Signing

Request Microsoft to clarify their treatment of OV vs EV CS certs and where
there is differentiation. (Ian) The only place of differentiation is
on-boarding for the Hardware Developer Centre Partner Program, which makes a
requirement for EV.  There are no other current differentiation anywhere.

Question from Bruce on how this is validated? (Ian) We are not looking at
the OID in the cert, we are more looking at the issuing CA, since its only
on application to the program. Microsoft is currently reviewing with the
Hardware Developer Centre folks to work out how this will be dealt with in
future.

Clarification requested from Bruce on whether its the case that EV no longer
helps with Reputation? (Ian) It is not the signer's reputation that is
paramount rather than the credentials they are using.

Clarification from Bruce as to whether Microsoft values SubjectInfo in EV
certs? (Ian) There is not a focus to put any value on EV-specific fields.

Clarification from Mohit as to whether that implies a move to OV in future?
(Ian) Microsoft is evaluating the bar between OV and EV and looking to
strike a balance between EV rigor and the effort for organizations around
the world to get it. We are trying to make it as simple as possible for the
ecosystem. So we are evaluating if an EV uplift is worth the value.

Suggestion from Bruce: take current BRs, and remove all EV related content
and see if it makes sense or whether the extra EV stuff is actually still
needed?

(Ian) The biggest challenge is how to provide clear communications to
developers about which certificate is required.

(Bruce) Perhaps the better approach is to decide where to go with this, and
then just work towards that.

Some discussion ensued about current validation of Organizations across all
the CABF working groups, and Bruce pointed out we already have 3 ways today,
and surely there was little value introducing a 4th specific to CS. To have
further discussion at the next F2F.

 

Meeting adjourned. Next

[Cscwg-public] Final minutes of CSCWG March 21, 2024

2024-04-18 Thread Dean Coclin via Cscwg-public

 

Minutes for CSCWG Call 21 Mar 2024

 

Agenda:

 

1.  Roll Call
2.  Antitrust reminder
3.  Minutes
4.  Ballots
5.  Membership
6.  Other business
7.  Next meeting - April 4th
8.  Adjourn

 

Attendees:

Dean Coclin (DigiCert), Martijn Katerbarg (Sectigo), Brianca Martin
(Amazon), Tim Crawford (CPA Canada/WebTrust), Thomas Zermeno (SSL.com),
Mohit Kumar (GlobalSign), Scott Rea (eMudhra, Mohit Kumar (GlobalSign),
Dimitris Zacharopoulos (HARICA), Atsushi INABA (GlobalSign), Inigo Barreira
(Sectigo)

 

Minutes:

Dean Coclin read the Antitrust policy.

 

Meeting minutes - No minutes to approve. Andrea Holland working on minutes
from F2F-New Delhi.

 

Ballots

*   CSC-23, Marking the EV Code Signing Guidelines Obsolete, in the
voting period, ends next week. Needs vote from Microsoft (only CA in the
group).
*   Removing EV guidelines references (in discussion) - imported the
latest changes from the CS BR's, ballot is ready, looking for 2 endorsers.
EV will not be removed, will likely enhance the validation methods of the
existing OV level.
*   Noted that a file on the wiki hasn't been changed in years. Not
included in the guidelines, needs chair approval to remove it.
*   Timestamping Private Key Protection - Incorporated feedback, ready
to start discussion period.

 

Membership

*   Identrust - Current associate member, requesting transition to full
membership in the CSWG. Server Cert Working Group (SCWG) approved them to be
a full member. Each working group needs to approve their status, membership
level can be different across groups. Ian (Microsoft) confirmed they have
the appropriate root in Windows and the appropriate audit (link provided in
the application). Request approved without objection. Dean to send
confirmation to Marco.
*   Keyfactor - Request to upgrade to become an associate member in the
CSWG. Noted for information that the request was approved by the SCWG.
Status has traditionally been used for groups like FederalPKI, Webtrust,
Etsy and companies that are in the process of applying for a root
certificate in a browser. This would be the 1st time for the CSWG that a
particular company would be given associate member status. It was noted that
they run a CA platform that several CA/B forum members use, may not
specifically be related to code signing. Discussion on Keyfactor was held at
the forum level during the F2F meeting. Concern was raised about setting a
bad precedent. Dean to discuss with Tim. Approval postponed to the next
meeting.

 

Other Business: None

 

Meeting adjourned. Next meeting April 4th.

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Broken Link


On https://wiki.netbsd.org/ports/evbarm/
Select NetBSD/evbarm 10.0 INSTALL notes
Produces Error 404.

Tom Dean

Re: RFR: 8329433: Reduce nmethod header size [v8]

On Thu, 18 Apr 2024 00:41:03 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Address comment

Marked as reviewed by dlong (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/18768#pullrequestreview-2007632424

Re: RFR: 8330388: Remove invokedynamic cache index encoding

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva  
wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), 
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and 
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic 
> operands needed to be rewritten to encoded values to better distinguish indy 
> entries from other cp cache entries. The above changes now distinguish 
> between entries with `to_cp_index()` using the bytecode, which is now 
> propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always 
> negative, leading to access errors if there is no matching decode call. These 
> calls are removed with some methods adjusted to distinguish between indices 
> with the bytecode. Verified with tier 1-5 tests.

@dougxc should check JVMCI changes.

-

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18819#pullrequestreview-2007498087

Re: RFR: 8330388: Remove invokedynamic cache index encoding

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva  
wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), 
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and 
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic 
> operands needed to be rewritten to encoded values to better distinguish indy 
> entries from other cp cache entries. The above changes now distinguish 
> between entries with `to_cp_index()` using the bytecode, which is now 
> propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always 
> negative, leading to access errors if there is no matching decode call. These 
> calls are removed with some methods adjusted to distinguish between indices 
> with the bytecode. Verified with tier 1-5 tests.

Did you consider minimizing changes by leaving 
decode_invokedynamic_index/encode_invokedynamic_index calls in place, but 
having the implementations not change the value?

-

PR Comment: https://git.openjdk.org/jdk/pull/18819#issuecomment-2062609288

Re: RFR: 8330388: Remove invokedynamic cache index encoding

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva  
wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), 
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and 
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic 
> operands needed to be rewritten to encoded values to better distinguish indy 
> entries from other cp cache entries. The above changes now distinguish 
> between entries with `to_cp_index()` using the bytecode, which is now 
> propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always 
> negative, leading to access errors if there is no matching decode call. These 
> calls are removed with some methods adjusted to distinguish between indices 
> with the bytecode. Verified with tier 1-5 tests.

src/hotspot/share/ci/ciEnv.cpp line 1513:

> 1511: // process the BSM
> 1512: int pool_index = indy_info->constant_pool_index();
> 1513: BootstrapInfo bootstrap_specifier(cp, pool_index, indy_index);

Why not just change the incoming parameter name to `index`?

src/hotspot/share/classfile/resolutionErrors.hpp line 60:

> 58: 
> 59:   // This function is used to encode an invokedynamic index to 
> differentiate it from a
> 60:   // constant pool index.  It assumes it is being called with a index 
> that is less than 0

Is this comment still correct?

src/hotspot/share/interpreter/bootstrapInfo.cpp line 77:

> 75: return true;
> 76:   } else if (indy_entry->resolution_failed()) {
> 77: int encoded_index = 
> ResolutionErrorTable::encode_indy_index(_indy_index);

That's an improvement, from two levels of encoding to only one!

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569625123
PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569626519
PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569627219

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Tue, 16 Apr 2024 16:09:21 GMT, Vladimir Kozlov  wrote:

>> src/hotspot/share/code/nmethod.cpp line 1441:
>> 
>>> 1439: int deps_size = align_up((int)dependencies->size_in_bytes(), 
>>> oopSize);
>>> 1440: int sum_size  = oops_size + metadata_size + deps_size;
>>> 1441: assert((sum_size >> 16) == 0, "data size is bigger than 64Kb: 
>>> %d", sum_size);
>> 
>> I suggest using checked_cast for the assignment below, rather than 
>> special-purpose checks here.
>
> Okay. But I will put above code under `#ifdef ASSERT` then.

The ASSERT block above looks unnecessary, now that field assignments below are 
using checked_cast.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1569496753

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

I think you'll want to ask port maintainers for aarch64/arm/ppc/riscv/s390 to 
review and test those changes.
There may be some opportunities for minor improvements, but those could be done 
later.  For example, we are computing `zlen` for the squareToLen stub even 
though the value is unused.  And both x86 and aarch64 seem to have unneeded 
save/restore code, even though I think all these registers are killed when 
called by a C2 runtime stub.

-

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2062138149

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6662:

> 6660:   push(tmp5);
> 6661: 
> 6662:   push(xlen);

There may be an opportunity here (separate RFE?) to get rid of the save/restore 
for these.  I don't think it's necessary if this is called as part of a C2 stub.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569452818

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

On Wed, 17 Apr 2024 19:45:02 GMT, Dean Long  wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   address comment.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:
> 
>> 4700: const Register tmp5  = r15;
>> 4701: const Register tmp6  = r16;
>> 4702: const Register tmp7  = r17;
> 
> No need for r17 or sorting tmps.  Make tmp0 r3, or r6, r7, etc.

Also, I don't see why the code below saves and restores r4/r5.  Maybe 
@theRealAph knows?  Aren't all these registers killed across a runtime call?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569427241

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693:

> 4691: const Register xlen  = r1;
> 4692: const Register z = r2;
> 4693: const Register zlen  = r3;

LibraryCallKit::inline_squareToLen() is still computing zlen and passing it as 
the 4th arg, even though the value is unused.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:

> 4700: const Register tmp5  = r15;
> 4701: const Register tmp6  = r16;
> 4702: const Register tmp7  = r17;

No need for r17 or sorting tmps.  Make tmp0 r3, or r6, r7, etc.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569419199
PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569420732

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4670:

> 4668: const Register tmp5  = r15;
> 4669: const Register tmp6  = r16;
> 4670: const Register tmp7  = r17;

Why not minimize changes and continue to use r5 for tmp0?  I see no need for 
r17 or to reassign all the other tmp registers.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569401544

[Cscwg-public] CSCWG Agenda April 18, 2024

2024-04-16 Thread Dean Coclin via Cscwg-public

MINUTE TAKER: NEED A VOLUNTEER, START RECORDING

 Bruce will run the meeting as I have a conflict this week

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (Andrea), March 21st (Brianca),
April 4th (Scott)
4.  Proposed ballots: Remove EV Guideline References
5.  Proposed ballot for Time-stamp Requirements update; CSC-24
6.  Other business
7.  Next meeting - May 2nd  
8.  Adjourn

 

 

Dean Coclin 

CSCWG Chair

 

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

2024-04-16 Thread Dean Rasheed

On Tue, 16 Apr 2024 at 11:35, Richard Guo  wrote:
>
> On Tue, Apr 16, 2024 at 5:48 PM Aleksander Alekseev 
>  wrote:
>>
>> Oversight of 0294df2f1f84 [1].
>>
>> [1]: 
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0294df2f1f84
>
> +1.  I think this change improves the code quality.  I searched for
> other arrays indexed by merge match kind, but found none.  So this patch
> seems thorough.
>

Yes this makes sense, though I note that some other similar code uses
a #define rather than inserting an enum element at the end (e.g.,
NUM_ROWFILTER_PUBACTIONS).

I guess the argument against inserting an enum element at the end is
that a switch statement on the enum value might generate a compiler
warning if it didn't have a default clause.

Looking at how NUM_ROWFILTER_PUBACTIONS is defined as the last element
plus one, it might seem to be barely any better than just defining it
to be 3, since any new enum element would probably be added at the
end, requiring it to be updated in any case. But if the number of
elements were much larger, it would be much more obviously correct,
making it a good general pattern to follow. So in the interests of
code consistency, I think we should do the same here.

Regards,
Dean

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Tue, 16 Apr 2024 03:12:48 GMT, Vladimir Kozlov  wrote:

>> src/hotspot/share/code/nmethod.hpp line 282:
>> 
>>> 280:   _has_flushed_dependencies:1, // Used for maintenance of 
>>> dependencies (under CodeCache_lock)
>>> 281:   _is_unlinked:1,  // mark during class unloading
>>> 282:   _load_reported:1;// used by jvmti to track if an 
>>> event has been posted for this nmethod
>> 
>> It seems like the type could be changed from uint8_t to bool.
>
> Is there difference in generated code when you use bool instead of uint8_t?
> I used uint8_t to easy change to uint16_t in a future if needed.

I don't think uint8_t vs uint16_t matters, only if it is signed, unsigned, or 
bool.  So if we have more than 8 individual :1 fields, it will expand to a 2nd 
byte.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566814258

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Tue, 16 Apr 2024 03:06:13 GMT, Vladimir Kozlov  wrote:

>> src/hotspot/share/code/nmethod.hpp line 205:
>> 
>>> 203:   // offsets to find the receiver for non-static native wrapper 
>>> frames.
>>> 204:   ByteSize _native_receiver_sp_offset;
>>> 205:   ByteSize _native_basic_lock_sp_offset;
>> 
>> Don't we need an assert in the accessor functions to make sure nmethod is 
>> native or not?
>
> I thought about that but in both places where these accessors are called 
> (`frame::get_native_monitor()` and `frame::get_native_receiver()`) there are 
> such asserts already:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/frame.cpp#L1085

OK, but I'd rather see it in the accessors too.  Some users are checking for 
method()->is_native() and others are checking for is_osr_method(), so we need 
to make sure those are always mutually exclusive: method()->is_native() != 
is_osr_method().

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566806754

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/memory/heap.hpp line 58:

> 56:   void set_length(size_t length) {
> 57: LP64_ONLY( assert(((length >> 32) == 0), "sanity"); )
> 58: _header._length = (uint32_t)length;

Suggestion:

_header._length = checked_castlength;

src/hotspot/share/memory/heap.hpp line 63:

> 61:   // Accessors
> 62:   void* allocated_space() const  { return (void*)(this + 
> 1); }
> 63:   size_t length() const  { return 
> (size_t)_header._length; }

This cast looks unnecessary.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566784458
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566784587

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.cpp line 1441:

> 1439: int deps_size = align_up((int)dependencies->size_in_bytes(), 
> oopSize);
> 1440: int sum_size  = oops_size + metadata_size + deps_size;
> 1441: assert((sum_size >> 16) == 0, "data size is bigger than 64Kb: %d", 
> sum_size);

I suggest using checked_cast for the assignment below, rather than 
special-purpose checks here.

src/hotspot/share/code/nmethod.cpp line 1445:

> 1443: _metadata_offset  = (uint16_t)oops_size;
> 1444: _dependencies_offset  = _metadata_offset  + 
> (uint16_t)metadata_size;
> 1445: _scopes_pcs_offset= _dependencies_offset  + (uint16_t)deps_size;

Use checked_cast instead of raw casts.

src/hotspot/share/code/nmethod.cpp line 1459:

> 1457: assert((data_offset() + data_end_offset) <= nmethod_size, "wrong 
> nmethod's size: %d < %d", nmethod_size, (data_offset() + data_end_offset));
> 1458: 
> 1459: _entry_offset  = 
> (uint16_t)offsets->value(CodeOffsets::Entry);

Use checked_cast.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566771026
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566772567
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566773477

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.cpp line 1235:

> 1233: int skipped_insts_size   = 
> code_buffer->total_skipped_instructions_size();
> 1234: #ifdef ASSERT
> 1235: assert(((skipped_insts_size >> 16) == 0), "size is bigger than 
> 64Kb: %d", skipped_insts_size);

Suggestion:


I think it's simpler just to use checked_cast below.

src/hotspot/share/code/nmethod.cpp line 1240:

> 1238: int consts_offset = 
> code_buffer->total_offset_of(code_buffer->consts());
> 1239: assert(consts_offset == 0, "const_offset: %d", consts_offset);
> 1240: #endif

Suggestion:

src/hotspot/share/code/nmethod.cpp line 1241:

> 1239: assert(consts_offset == 0, "const_offset: %d", consts_offset);
> 1240: #endif
> 1241: _skipped_instructions_size = (uint16_t)skipped_insts_size;

Suggestion:

_skipped_instructions_size = 
checked_cast(code_buffer->total_skipped_instructions_size());

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566764300
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566765068
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566759786

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.hpp line 205:

> 203:   // offsets to find the receiver for non-static native wrapper 
> frames.
> 204:   ByteSize _native_receiver_sp_offset;
> 205:   ByteSize _native_basic_lock_sp_offset;

Don't we need an assert in the accessor functions to make sure nmethod is 
native or not?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566634384

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.hpp line 282:

> 280:   _has_flushed_dependencies:1, // Used for maintenance of 
> dependencies (under CodeCache_lock)
> 281:   _is_unlinked:1,  // mark during class unloading
> 282:   _load_reported:1;// used by jvmti to track if an 
> event has been posted for this nmethod

It seems like the type could be changed from uint8_t to bool.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566631312

Re: RFR: 8329433: Reduce nmethod header size [v3]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/codeBlob.cpp line 120:

> 118: 
> 119:   _header_size((uint16_t)header_size),
> 120:   _frame_complete_offset((int16_t)CodeOffsets::frame_never_safe),

See above.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566604310

Re: RFR: 8329433: Reduce nmethod header size [v3]