LibreSSL 3.7.0 Released

A new development release of LibreSSL is out, and should be arriving on a mirror near you shortly.

Brent Cook (bcook@)’s announcement reads,

We have released LibreSSL 3.7.0, which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon. This is a
development release from the 3.7.x branch, which will eventually ship
with OpenBSD 7.3.

Read more…

Andy Wingo: i’m throwing ephemeron party & you’re invited

Good day, hackfolk. Today’s note tries to extend our semi-space
collector with support for ephemerons. Spoiler alert: we fail in a
subtle and interesting way. See if you can spot it before the end 🙂

Recall that, as we concluded in an earlier
article
,
a memory manager needs to incorporate ephemerons as a core part of the
tracing algorithm. Ephemerons are not macro-expressible in terms of
object trace functions.

Instead, to support ephemerons we need to augment our core trace
routine. When we see an ephemeron E, we need to check if the key K
is already visited (and therefore live); if so, we trace the value V
directly, and we’re done. Otherwise, we add E to a global table of
pending ephemerons T, indexed under K. Finally whenever we trace a
new object O, ephemerons included, we look up O in T, to trace any
pending ephemerons for O.

So, taking our semi-space
collector

as a workbench, let’s start by defining what an ephemeron is.

struct gc_ephemeron {
  struct gc_obj header;
  int dead;
  struct gc_obj *key;
  struct gc_obj *value;
};

enum gc_obj_kind { ..., EPHEMERON, ... };

static struct gc_ephemeron* as_ephemeron(struct gc_obj *obj) {
  uintptr_t ephemeron_tag = NOT_FORWARDED_BIT | (EPHEMERON << 1);
  if (obj->tag == ephemeron_tag)
    return (struct gc_ephemeron*)obj;
  return NULL;
}

First we need to allow the GC to know when an object is an ephemeron or
not. This is somewhat annoying, as you would like to make this concern
entirely the responsibility of the user, and let the GC be indifferent
to the kinds of objects it’s dealing with, but it seems to be
unavoidable.

The heap will need some kind of data structure to track pending
ephemerons:

struct gc_pending_ephemeron_table;

struct gc_heap {
  ...
  struct gc_pending_ephemeron_table *pending_ephemerons;
}

struct gc_ephemeron *
pop_pending_ephemeron(struct gc_pending_ephemeron_table*,
                      struct gc_obj*);
struct gc_ephemeron *
add_pending_ephemeron(struct gc_pending_ephemeron_table*,
                      struct gc_obj*, struct gc_ephemeron*);
struct gc_ephemeron *
pop_any_pending_ephemeron(struct gc_pending_ephemeron_table*);

Now let’s define a function to handle ephemeron shenanigans:

void visit_ephemerons(struct gc_heap *heap, struct gc_obj *obj) {
  // We are visiting OBJ for the first time.
  // OBJ is the old address, but it is already forwarded.
  ASSERT(is_forwarded(obj));

  // First, visit any pending ephemeron for OBJ.
  struct gc_ephemeron *ephemeron;
  while ((ephemeron =
            pop_pending_ephemeron(heap->pending_ephemerons, obj))) {
    ASSERT(obj == ephemeron->key);
    ephemeron->key = forwarded(obj);
    visit_field(&ephemeron->value, heap);
  }

  // Then if OBJ is itself an ephemeron, trace it.
  if ((ephemeron = as_ephemeron(forwarded(obj)))
      && !ephemeron->dead) {
    if (is_forwarded(ephemeron->key)) {
      ephemeron->key = forwarded(ephemeron->key);
      visit_field(&ephemeron->value, heap);
    } else {
      add_pending_ephemeron(heap->pending_ephemerons,
                            ephemeron->key, ephemeron);
    }
  }
}

struct gc_obj* copy(struct gc_heap *heap, struct gc_obj *obj) {
  ...
  visit_ephemerons(heap, obj); // *
  return new_obj;
}

We wire it into the copy routine, as that’s the bit of the collector
that is called only once per object and which has access to the old
address. We actually can’t process ephemerons during the Cheney field
scan, as there we don’t have old object addresses.

Then at the end of collection, we kill any ephemeron whose key hasn’t
been traced:

void kill_pending_ephemerons(struct gc_heap *heap) {
  struct gc_ephemeron *ephemeron;
  while ((ephemeron =
            pop_any_pending_ephemeron(heap->pending_ephemerons)))
    ephemeron->dead = 1;    
}

void collect(struct gc_heap *heap) {
  // ...
  kill_pending_ephemerons(heap);
}

First observation: Gosh, this is quite a mess. It’s more code than the
core collector, and it’s gnarly. There’s a hash table, for goodness’
sake. Goodbye, elegant algorithm!

Second observation: Well, at least it works.

Third observation: Oh. It works in the same way as tracing in the
copy
routine

works: well enough for shallow graphs, but catastrophically for
arbitrary graphs. Calling visit_field from within copy introduces
unbounded recursion, as tracing one value can cause more ephemerons to
resolve, ad infinitum.

Well. We seem to have reached a dead-end, for now. Will our hero wrest
victory from the jaws of defeat? Tune in next time for find out: same
garbage time (unpredictable), same garbage channel (my wordhoard). Happy hacking!

Ehsaas Telethon – Winter Appeal – 12th December 2022 – Part 2 – ARY Qtv

Ehsaas Telethon – Winter Appeal – 12th December 2022 – Part 2 – ARY Qtv

Subscribe Here: https://bit.ly/3dh3Yj1

#EhsaasTelethon #WinterAppeal #ARYQtv

Official Facebook: https://www.facebook.com/ARYQTV/
Official Website: https://aryqtv.tv/
Watch ARY Qtv Live: http://live.aryqtv.tv/
Programs Schedule: https://aryqtv.tv/schedule/
Islamic Information: https://bit.ly/2MfIF4P
Android App: https: //bit.ly/33wgto4
Ios App: https: https://apple.co/2v3zoXW

Decoliner: The $500,000 Double-Decker Motorhome | RIDICULOUS RIDES

A RENOWNED automotive artist has built a $500,000 motorhome that you can drive from the roof. Randy Grubb, from Oregon, is well-known for building beautiful and unique chrome vehicles. Some of his masterpieces include the Blastolene Indy Special, Jay Leno Tank Car, Decoson and the $500,000 motorhome – the Decoliner. Inspired by the 1980s sci-fi space traveller Flash Gordon, Randy spent over $100,000 in parts and 6,000 hours in manpower on the stylised mobile home. Using the chassis of a 1973 GMC motorhome which sports a front-wheel drive, it allows the frame of the Decoliner to be very low to the ground, around 14 inches. This means that Randy had enough space to stack the vehicle as a double decker and for an additional driving position on the roof low enough to fit under most bridges and overpasses. Randy and his wife drove the Decoliner all over America, putting over 15,000 miles on the camper without being stopped for the unusual driving position. Randy told Barcroft TV: “I always get asked ‘is that legal?’ Well, it’s not illegal.” Recently, Randy was invited to the Frankenmuth Auto-Fest in Michigan to show off the 26ft aluminium Decoliner. Joining Randy was the new owner of motorhome, Mike Jahns, who first saw the mobile home on TV and fell in love with the art-deco design of the vehicle. “It’s an amazing vehicle to be involved with because everybody smiles profusely at it, it just brings a lot of joy to people,” Mike said.

Indian Navy opens its door for women to Join its elite unit ‘MARCOS’ | Oneindia News | *Explainer

The Indian Navy has finally decided to open its door to women candidates for its elite special force unit the MARCOS. This is a watershed moment in the history of the forces as this move would allow women to serve as commandos for the first time in any of the three defence services in the country. In this video, we bring to you facts about MARCOS a very specialized and elite force of the country. But before that, don’t forget to like, share and subscribe to Oneindia.

#Marcos #Marcosspecialforce #Marinecomandos

08 Best SEO Techniques for 2023

08 Best SEO Techniques for 2023 | Best SEO Trends in 2023 | Ads Optimiser
1. Voice Search
2. Mobile Optimisation
3. Semantic keywords
4. Building Quality Backlinks

need quality backlinks NOT QUANTITY
Classified Posts, Social Bookmarking, Image Submissions, Business Listing, Profile creation and Guest Posting.

5. Business Listing or Local Listing
6. User Experience or UI
7. Schema Markup
8. Website Load Speed

The above are the rules for SEO in 2023. If you want to get quality traffic for your business then implement the above for your business in the coming year. Definitely, you will have more traffic, leads and finally more conversion.

#bestseotipsfor2023 #seotips2023 #seotechniques2023
#seoservices #searchengineoptimisation #seocompany
#digitalmarketingagency #digitalmarketingservices

Related Videos:-
How to Add Star Rating Rich Snippets on WordPress Posts with plugins & without it for other websites
https://youtu.be/9rL1L5SRqSU

Setting up goals in Google Analytics | Ads Optimiser
https://youtu.be/guXJsD52J9U

Target Multiple Cities With the Same Website | SEO Case Studies
https://youtu.be/6ztmtRw7E3s

Google Display Ads Case Studies – II | Ads Optimiser
https://youtu.be/I5y6vYDiU5I

#! code: Drupal 9: Loading Configuration Entities Using Entity Query

Whilst working on a module I found that I needed to do something that was difficult to find information for. I think part of that is because the solution is simpler than I was thinking, but it did cause me to get lost in source code and internet issues for a while.

What I needed to do was to load in a list of configuration entities that matched certain parameters. The configuration entity I was dealing with was used to manipulate the output of a form, but only if certain conditions were met first. I thought that this information might be useful to others who are looking to load configuration entities.

In this article I will show how to search for configuration entities and how to load those entities once found. I’ll be using blocks for the examples here, but the same rules will apply to any configuration entities you want to load.

Loading The Entity Query Service

What we need to do first is get the entity query service. In case it wasn’t obvious (and it wasn’t to me) you can search for configuration entities in the same way as you would any other sort of entity. If you have used entity query to find users or pages of content then this is the same mechanism. There are, however, a couple of ways to go about doing this.

The first (and simplest) way of loading entity query is to just grab the object for the configuration entity we want to load.

$entityQuery = Drupal::entityQuery('block');

Whilst using this method does allow us to search for configuration entities, it doesn’t allow us to load those entities. To do that we need to use entity_type.manager service to find the storage for the configuration entity we want to load.

Read more.

BIOS Memory Map for vmd(8) Rewrite in Progress

A rewritten version of vmd(8)‘s BIOS memory map handling could soon be appearing in -current.

In a recent post to tech@ and supplemented by an accompanying post to ports@ since the changes touch on SeaBIOS, Dave Voutila (dv@) describes the changes and the motiviation for changing them, ie

In short, this nukes some old hacks we've been carrying to communicate
things like >4GB of memory to SeaBIOS via CMOS. It assumes vmd(8)
properly builds and conveys a bios e820 memory map via the fw_cfg api.

Follow the links to the messages for the full story, test the patches if you feel up to it. While the ETA of the upcoming commit is not yet certain, expect to see this change go in soon.

Andy Wingo: we iterate so that you can recurse

Sometimes when you see an elegant algorithm, you think “looks great, I
just need it to also do X”. Perhaps you are able to build X directly
out of what the algorithm gives you; fantastic. Or, perhaps you can
alter the algorithm a bit, and it works just as well while also doing X.
Sometimes, though, you alter the algorithm and things go pear-shaped.

Tonight’s little note builds on yesterday’s semi-space collector
article

and discusses an worse alternative to the Cheney scanning algorithm.

To recall, we had this visit_field function that takes a edge in the
object graph, as the address of a field in memory containing a struct gc_obj*. If the edge points to an object that was already copied,
visit_field updates it to the forwarded address. Otherwise it copies the object,
thus computing the new address, and then updates the field.

struct gc_obj* copy(struct gc_heap *heap, struct gc_obj *obj) {
  size_t size = heap_object_size(obj);
  struct gc_obj *new_obj = (struct gc_obj*)heap->hp;
  memcpy(new_obj, obj, size);
  forward(obj, new_obj);
  heap->hp += align_size(size);
  return new_obj;
}

void visit_field(struct gc_obj **field, struct gc_heap *heap) {
  struct gc_obj *from = *field;
  struct gc_obj *to =
    is_forwarded(from) ? forwarded(from) : copy(heap, from);
  *field = to;
}

Although a newly copied object is in tospace, all of its fields
still point to fromspace. The Cheney scan algorithm later visits the
fields in the newly copied object with visit_field, which both
discovers new objects and updates the fields to point to tospace.

One disadvantage of this approach is that the order in which the objects
are copied is a bit random. Given a hierarchical memory system, it’s
better if objects that are accessed together in time are close together
in space. This is an impossible task without instrumenting the actual
data access in a program and then assuming future accesses will be like the
past. Instead, the generally-accepted solution is to ensure that
objects that are allocated close together in time be adjacent in
space. The bump-pointer allocator in a semi-space collector provides
this property, but the evacuation algorithm above does not: it would
need to preserve allocation order, but instead its order is driven by
graph connectivity.

I say that the copying algorithm above is random but really it favors a
breadth-first traversal; if you have a binary tree, first you will copy
the left and the right nodes of the root, then the left and right
children of the left, then the left and right children of the right,
then grandchildren, and so on. Maybe it would be better to keep parent
and child nodes together? After all they are probably allocated that
way.

So, what if we change the algorithm:

struct gc_obj* copy(struct gc_heap *heap, struct gc_obj *obj) {
  size_t size = heap_object_size(obj);
  struct gc_obj *new_obj = (struct gc_obj*)heap->hp;
  memcpy(new_obj, obj, size);
  forward(obj, new_obj);
  heap->hp += align_size(size);
  trace_heap_object(new_obj, heap, visit_field); // *
  return new_obj;
}

void visit_field(struct gc_obj **field, struct gc_heap *heap) {
  struct gc_obj *from = *field;
  struct gc_obj *to =
    is_forwarded(from) ? forwarded(from) : copy(heap, from);
  *field = to;
}

Here we favor a depth-first traversal: we eagerly call
trace_heap_object within copy. No need for the Cheney scan
algorithm; tracing does it all.

void collect(struct gc_heap *heap) {
  flip(heap);
  uintptr_t scan = heap->hp;
  trace_roots(heap, visit_field);
}

The thing is, this works! It might even have better performance for
some workloads, depending on access patterns. And yet, nobody does
this. Why?

Well, consider a linked list with a million nodes; you’ll end up with a
million recursive calls to copy, as visiting each link eagerly
traverses the next. While I am all about unbounded
recursion
, an
infinitely extensible stack is something that a language runtime has to
provide to a user, and here we’re deep into
implementing-the-language-runtime territory. At some point a user’s
deep heap graph is going to cause a gnarly system failure via stack
overflow.

Ultimately stack space needed by a GC algorithm counts towards collector
memory overhead. In the case of a semi-space collector you already need
twice the amount memory as your live object graph, and if you recursed
instead of iterated this might balloon to 3x or more, depending on the
heap graph shape.

Hey that’s my note! All this has been context for some future article,
so this will be on the final exam. Until then!